hacking: described new branching policy for 1.12 an later

This change closes automake bug#11153.

* HACKING (Working with git): Document the new policy for automake
branching and merging, which will start being applied after 1.12 is
released:

  - the maintenance branch will be 'maint', and we will cut the
    maintenance releases directly from there;

  - the development branch will be 'master', and we will cut the
    new releases directly from there;

  - 'maint' will be kept regularly merged into 'master'.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>

1 files changed, 16 insertions, 37 deletions

diff --git a/HACKING b/HACKING
index 29c0e4aa7..8d3471fc1 100644
--- a/HACKING
+++ b/HACKING
@@ -103,37 +103,22 @@
   latest stable version of Autoconf installed and available early
   in your PATH.
 
-* The git tree currently carries a number of branches: master for the
-  current development, and release branches named branch-X.Y.  The maint
-  branch serves as common ground for both master and the active release
-  branches.  Changes intended for both should be applied to maint, which
-  should then be merged to release branches and master, of course after
-  suitable testing.  It is advisable to merge only after a set of related
-  commits have been applied.
-
-* Example work flow for patches to maint:
-
-  # 1. Checkout the "maint" branch:
-  git checkout maint
-
-  # 2. Apply the patch(es) with "git am" (or create them with $EDITOR):
-  git am -3 0*.patch
-  # 2a. Run required tests, if any ...
-
-  # 3. Merge maint into branch-1.11:
-  git checkout branch-1.11
-  git merge maint
-  # 3a. Run required tests, if any ...
-
-  # 4. Redo steps 3 and 3a for master:
-  git checkout master
-  git merge maint
-  # testing ...
-
-  # 5. Push the maint and master branches:
-  git push --dry-run origin maint branch-1.11 master
-  # if all seems ok, then actually push:
-  git push origin maint branch-1.11 master
+* The Automake git tree currently carries two basic branches: 'master' for
+  the current development, and 'maint' for maintenance and bug fixes.  The
+  maint branch should be kept regularly merged into the master branch.
+  It is advisable to merge only after a set of related commits have been
+  applied, to avoid introducing too much noise in the history.
+
+* 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 or might be merged later.
+  in the future, we might introduce a special branch named 'next' that
+  may serve as common ground for feature merging and testing, should
+  they not yet be ready for master.
+
+* After a major release is done, the master branch is to be merged into
+  the maint branch, and then a "new" master branch created stemming
+  from the resulting commit.
 
 * When fixing a bug (especially a long-standing one), it may be useful
   to commit the fix to a new temporary branch based off the commit that
@@ -141,12 +126,6 @@
   the active branches descending from the buggy commit.  This offers a
   simple way to fix the bug consistently and effectively.
 
-* 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 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
   actual patches were merged even when they don't appear early in the list.