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.