CVS branching -> Git branching model

[Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>]

I think we should leave the current CVS-style branching model and make
better use of Git.

'master' is currently two things:  The development branch, and getting
in the way it's an abandonware repository:  slapmodify, vc, etc.
Maybe that's harsh, but if it is not abandonware, why are the authors
not finishing it so it can be released?  Some of it is years old.

The justification for keeping a bunch of features under development in
master instead of feature branches was to get more eyes and testers for
them.  Well, OK, if the features were underway to be finished and
released.  But that's not working out.

So I suggest we reclassify such code as abandonware and throw it out of
master.  Maybe except code behind #ifdef LDAP_DEVEL which is safe to
include in releases.  If this prompts someone to finish some code so it
can be released, great.  Otherwise the reclassification is correct.

The code is still in the repo.  Someone can recreate it as a feature
branch if they care.  If some is for RE25, let's make a RE25 branch.

If we are going to keep avoiding feature branches and put unfinished
stuff in the devel branch, well OK, limited to code which _will_ get
released soon and code behind #ifdef LDAP_DEVEL which can be in releases
anyway.  Otherwise after a while send the author a nastygram, revert the
code, maybe re-revert it into a feature branch so it's not forgotten.

We can still have a branch with all such unfinished code:  See the 'pu'
branch in the gitworkflows(7) manpage.  It merges the feature branches.
RE25 above could be another such branch of merged features.


Another issue is that we sometimes want a quick release - normally for a
regression in last release - but OPENLDAP_REL_ENG_2_4 is not in shape to
be released.  So we wait, or end up with a quicka release wich is a
bugfix release with some other hopefully-OK code.


So, something like the following:

- 'maint' branch:  Planned releases, like today's OPENLDAP_REL_ENG_2_4.

- Temporary 'hotfix' or 'itsNNNN' branches, branched off last release:
  Quick unplanned releases, when 'maint' is not in shape to be released
  quickly.  After release, merge the branch into 'maint' and delete it.

- Some sort of 'devel' branch, branched off 'maint' and current
  'master', merging 'maint' after releases.

  Like to today's 'master' but without unfinished features other than
  code behind #ifdef LDAP_DEVEL.  That way it can be merged into maint
  now and then (like before a release), which has to be easier than
  cherry-picking all the time.

- Feature branches for long-lived unfinished features.  Merged into 'pu'
  below, and hopefully eventually into the other branches.

- 'pu', branching off 'devel' and merging the feature branches, so it
  looks like today's 'master'.  Needs to be thrown away and recreated
  now and then to avoid clutter.

'maint' or 'devel' above would be named 'master'. I don't care which.


Completed feature branches can merge into the branch they branched off.
A feature branched off devel cannot merge into maint, since it'd drag
devel features with it.  So it'd be really nice to keep merging devel
into maint now and then, instead of cherry-picking.


One final issue, I'd like to get rid of the clutter of old branches and
tags from CVS which are no longer of any use.  Either delete them, or
rename to refs/archive/<heads,tags>/<name>.  'git clone' without
'--mirror' will not clone these.

-- 
Hallvard