maint: modernize README-{hacking,prereq}

1 files changed, 61 insertions, 27 deletions

diff --git a/README-hacking b/README-hacking
index 77096b0e..44cb75b9 100644
--- a/README-hacking
+++ b/README-hacking
@@ -1,35 +1,47 @@
--*- outline -*-
+Building from a Git repository				-*- outline -*-
 
 These notes intend to help people working on the checked-out sources.
 These requirements do not apply when building from a distribution tarball.
+If this package has a file HACKING, please also read that file for
+more detailed contribution guidelines.
 
 * Requirements
 
-We've opted to keep only the highest-level sources in the GIT repository.
-This eases our maintenance burden, (fewer merges etc.), but imposes more
+We've opted to keep only the highest-level sources in the Git repository.
+This eases our maintenance burden (fewer merges etc.), but imposes more
 requirements on anyone wishing to build from the just-checked-out sources.
-Note the requirements to build the released archive are much less and
-are just the requirements of the standard ./configure && make procedure.
+(The requirements to build from a release are much less and are just
+the requirements of the standard './configure && make' procedure.)
 Specific development tools and versions will be checked for and listed by
 the bootstrap script.  See README-prereq for specific notes on obtaining
 these prerequisite tools.
 
 Valgrind <http://valgrind.org/> is also highly recommended, if
-Valgrind supports your architecture. See also README-valgrind.
+Valgrind supports your architecture.  See also README-valgrind
+(if present).
 
 While building from a just-cloned source tree may require installing a
-few prerequisites, later, a plain 'git pull && make' should be sufficient.
+few prerequisites, later, a plain 'git pull && make' typically suffices.
 
-* First GIT checkout
+* First Git checkout
 
 You can get a copy of the source repository like this:
 
-        $ git clone git://git.sv.gnu.org/grep
-        $ cd grep
+        $ git clone git://git.sv.gnu.org/<packagename>
+        $ cd <packagename>
 
-As an optional step, if you already have a copy of the gnulib git
-repository on your hard drive, then you can use it as a reference to
-reduce download time and disk space requirements:
+where '<packagename>' stands for 'coreutils' or whatever other package
+you are building.
+
+To use the most-recent Gnulib (as opposed to the Gnulib version that
+the package last synchronized to), do this next:
+
+        $ git submodule foreach git pull origin master
+        $ git commit -m 'build: update gnulib submodule to latest' gnulib
+
+As an optional step, if you already have a copy of the Gnulib Git
+repository, then you can use it as a reference to reduce download
+time and file system space requirements:
 
         $ export GNULIB_SRCDIR=/path/to/gnulib
 
@@ -38,20 +50,14 @@ which are extracted from other source packages:
 
         $ ./bootstrap
 
-To use the most-recent gnulib (as opposed to the gnulib version that
-the package last synchronized to), do this next:
-
-        $ git submodule foreach git pull origin master
-        $ git commit -m 'build: update gnulib submodule to latest' gnulib
-
 And there you are!  Just
 
-        $ ./configure --quiet #[--enable-gcc-warnings] [*]
+        $ ./configure --quiet #[--disable-gcc-warnings] [*]
         $ make
         $ make check
 
 At this point, there should be no difference between your local copy,
-and the GIT master copy:
+and the Git master copy:
 
         $ git diff
 
@@ -59,12 +65,40 @@ should output no difference.
 
 Enjoy!
 
-[*] The --enable-gcc-warnings option is useful only with glibc
-and with a very recent version of gcc.  You'll probably also have
-to use recent system headers.  If you configure with this option,
-and spot a problem, please be sure to send the report to the bug
-reporting address of this package, and not to that of gnulib, even
-if the problem seems to originate in a gnulib-provided file.
+[*] By default GCC warnings are enabled when building from Git.
+If you get warnings with recent GCC and Glibc with default
+configure-time options, please report the warnings to the bug
+reporting address of this package instead of to bug-gnulib,
+even if the problem seems to originate in a Gnulib-provided file.
+If you get warnings with other configurations, you can run
+'./configure --disable-gcc-warnings' or 'make WERROR_CFLAGS='
+to build quietly or verbosely, respectively.
+-----
+
+* Submitting patches
+
+If you develop a fix or a new feature, please send it to the
+appropriate bug-reporting address as reported by the --help option of
+each program.  One way to do this is to use vc-dwim
+<https://www.gnu.org/software/vc-dwim/>), as follows.
+
+  Run the command "vc-dwim --initialize" from the top-level directory
+  of this package's git-cloned hierarchy.
+
+  Edit the (empty) ChangeLog file that this command creates, creating a
+  properly-formatted entry according to the GNU coding standards
+  <https://www.gnu.org/prep/standards/html_node/Change-Logs.html>.
+
+  Make your changes.
+
+  Run the command "vc-dwim" and make sure its output (the diff of all
+  your changes) looks good.
+
+  Run "vc-dwim --commit".
+
+  Run the command "git format-patch --stdout -1", and email its output
+  in, using the output's subject line.
+
 -----
 
 Copyright (C) 2002-2021 Free Software Foundation, Inc.