[PATCH 1/7] hacking: miscellaneous minor fixes

[Stefano Lattarini]

* HACKING (Administrivia): If a commit fixes a bug registered at GNU
debbugs, its bug number be reported in the ChangeLog entry.  Re-order
the entries to give more visibility to the advice on how to verify
that a commit really fixes a bug.
(Working with git): Improve advice about which pre-existing branch
a topic branch should be based on.
---
 HACKING |   16 +++++++++-------
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/HACKING b/HACKING
index 873243c..c01445f 100644
--- a/HACKING
+++ b/HACKING
@@ -10,12 +10,18 @@
 ================================================================
 = Administrivia
 
+* The correct response to most actual bugs is to write a new test case
+  which demonstrates the bug.  Then fix the bug, re-run the test suite,
+  and check everything in.
+
 * If you incorporate a change from somebody on the net:
   First, if it is a large change, you must make sure they have signed the
   appropriate paperwork.
   Second, be sure to add their name and email address to THANKS
 
 * If a change fixes a test, mention the test in the ChangeLog entry.
+  If a change fixes a bug registered in the Automake debbugs tracker,
+  mention the bug number in the ChangeLog entry.
 
 * If somebody reports a new bug, mention his name in the ChangeLog entry
   and in the test case you write.  Put him into THANKS.
@@ -24,10 +30,6 @@
   sure to add a test case for it, and to reference such test case from
   a proper Texinfo comment.
 
-* The correct response to most actual bugs is to write a new test case
-  which demonstrates the bug.  Then fix the bug, re-run the test suite,
-  and check everything in.
-
 * Some files in the automake package are not owned by automake.  These
   files should never be edited here.  These files are
       COPYING (from FSF),
@@ -151,9 +153,9 @@
 
 * There may be a number of longer-lived feature branches for new developments.
   They should be based off of a common ancestor of all active branches to
-  which the feature should be merged later.  The next branch may serve as
-  common ground for feature merging and testing, should they not be ready
-  for master yet.
+  which the feature should or might be merged later.  The next branch may
+  serve as common ground for feature merging and testing, should they not
+  be ready for master yet.
 
 * For merges from branches other than maint, prefer 'git merge --log' over
   plain 'git merge', so that a later 'git log' gives an indication of which
-- 
1.7.2.3