Historic and proposed future use of branches in the findutils repository

[James Youngman]

This email is intended to do two things:

1. Summarize the historic use of branches in the Findutils repository
(since I now see that this has been a bit unclear to downstream
packagers).
2. Propose a future arrangement that more directly suits both
downstream packagers and committers (the fact that these people
overlap a bit being unimportant for this discussion).


1) Historic use of branches

There is no source revision information in the git repository for
findutils releases prior to 4.1.   Much of the subsequent work was
done in CVS and the CVS repository was converted to git some years
ago.  Some of the branches now in git were made in CVS, which accounts
for some of the odd naming.  You can see all the current branches in
the public git repository here:
http://git.savannah.gnu.org/cgit/findutils.git/refs/heads

Some of these branches have a still-meaningful purpose:

rel-4-2-fixes - the 4.2.x release series
rel-4-3-fixes - the 4.3.x release series
rel-4-4-fixes - the 4.4.x release series
rel-4-6-fixes - the 4.6.x release series; this is where, currently,
stable releases are made
master - the development code; development always happens here, though
some patches are cherry-picked or otherwise included in the other
branches (e.g. to make bugfix releases on the stable branch).

>From master, we would currently cut releases for 4.7.x, though as yet
there have actually been no 4.7.x releases.

Under CVS it was not possible to have a "private" branch and so the
git repository contains a number of artifacts that are now basically
obsolete but haven't been removed:

Debian_stable - Kevin Dalley (the previous GNU findutils maintainer)
was also the Debian maintainer for the findutils package.    I thin he
kept Debian-specific things here.
debian - Also Kevin's thing, and I don't know how this relates to Debian_stable.
FINDUTILS - I'm not sure what this is.  Perhaps the vendor branch from
the CVS repository.
fts-conversion - a CVS branch I made in preparation for switching to
gnulib's fts.  In git terminology it was a topic branch.  It's long
obsolete.
jy_branch_2003_05_24_gnulib_update - similarly a topic branch.
master-UNNAMED-BRANCH - this seems to be an artifact of the CVS-to-git
translation process.
master-UNNAMED-BRANCH-UNNAMED-BRANCH - this seems to be an artifact of
the CVS-to-git translation process.


2) Proposed arrangement for the future

a) Future of "master": continue to use it for development, but also
cut "stable" releases directly from here.   Abandon the use of
"stable" branches.  Instead, develop on master and cut stable releases
from there, directly.   Expect committers to do any destabilizing work
mostly on private topic branches, though with the option of creating
shared topic branches (in the Savannah repository) for any large
destabilizing projects needing collaboration.

b) rel-4-6-fixes : stop using this as a (current) stable release
branch ... in other words, discontinue the use of this, merge it into
master, or obsolete it by creating a 4.8.x release on master.

c) other rel-xxxx-fixes branches: keep these for historical record.

d) The other branches could be deleted from the Savannah git
repository since they're no longer used and are simply confusing.
Prior to deleting these we could ask the FSF to somehow archive the
existing (pre-branch-deletion) git repository.  (better ideas
welcome).

I believe that this proposal matches the preferences of the downstream
maintainers (in so far as they each have a preference).  I believe
this arrangement is also easier for committers due to the lack of a
need to cherry-pick changes onto a "stable" release branch.

Thoughts, improvements, suggestions, feedback?

James.