maint: Update HACKING

* HACKING (Working with git): Remove reference to the 'micro' branch and
adapt branch descriptions to the current branching scheme.

1 files changed, 12 insertions, 18 deletions

diff --git a/HACKING b/HACKING
index 8e7764baf..ded1c7ff4 100644
--- a/HACKING
+++ b/HACKING
@@ -156,15 +156,8 @@
   latest stable version of Autoconf installed and available early
   in your PATH.
 
-* The Automake git tree currently carries three basic branches: 'micro',
-  'maint' and 'master'.
-
-* The 'maint' branch, reserved to changes that should go into the next
-  micro release; so it will just see fixes for regressions, trivial
-  bugs, or documentation issues, and no "active" development whatsoever.
-  Since emergency regression-fixing or security releases could be cut
-  from this branch at any time, it should always be kept in a releasable
-  state.
+* The Automake git tree currently carries three basic branches: 'master',
+  'next' and 'maint'.
 
 * The 'master' branch is where the development of the next release
   takes place.  It should be kept in a stable, almost-releasable state,
@@ -172,6 +165,16 @@
   this is not a hard rule, and such "stability" is not expected to be
   absolute (emergency releases are cut from the 'maint' branch anyway).
 
+* When planning a release a dedicated branch should be created and after
+  the release is done, the release branch is to be merged both into the
+  'master' branch and the 'maint' branch.
+
+* Besides merges from release branches, the 'maint' branch can contain
+  fixes for regressions, trivial bugs, or documentation issues, that
+  will be part of an emergency regression-fixing or security releases.
+  As a consequence it should always be kept in a releasable state and no
+  "active" development should be done whatsoever.
+
 * The 'next' branch is reserved for the development of the next major
   release.  Experimenting a little is OK here, but don't let the branch
   grow too unstable; if you need to do exploratory programming or
@@ -187,15 +190,6 @@
   developments.  They should be based off of a common ancestor of all
   active branches to which the feature should or might be merged later.
 
-* After a release is done, the release branch is to be merged both
-  into the 'master' branch and the 'maint' branch.
-
-* 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
-  introduced the bug.  Then this "bugfix branch" can be merged into all
-  the active branches descending from the buggy commit.  This offers a
-  simple way to fix the bug consistently and effectively.
-
 * When merging, 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.