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.
