* 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
