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.
I wrote:
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.
Er, s/before/after/ a release:-)
--On Tuesday, January 31, 2012 12:11 PM +0100 Hallvard Breien Furuseth h.b.furuseth@usit.uio.no wrote:
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.
Abandonware? What are you talking about? Both of those, AFAIK, are 2.5 features, which is why they haven't been released. Some things have been in there for years because 2.4 has been the release branch for years (2007) and there has been very little 2.5 development that necessitates a 2.5 release. Last I checked the roadmap for 2.5, it hadn't been updated in ages, and there has been very little development of the features listed on it in any case.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Tuesday, January 31, 2012 12:11 PM +0100 Hallvard Breien Furuseth h.b.furuseth@usit.uio.no wrote:
I think we should leave the current CVS-style branching model andmake 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.
Abandonware? What are you talking about? Both of those, AFAIK, are 2.5 features, which is why they haven't been released.
Aha, I hadn't caught that. I remember slapmodify (or the companion LDIF api?) is buggy and had the distinct impression that this is well known. I may have been thinking of contrib:ucn rather than contrib:vc. <grepping...> a note from hyc @ irc: "ITSs against it [usn] should be discarded since we already know it's not meant to be used". WTF...
Anyway, why can't slapmodify, <libldif replacement>, vc be finished and go in RE24? contrib/ stuff does not get in the way, but companion libldap/slapd differences beween master and RE24 do. They get in the way of testing, cherry-picking etc.
Some things have been in there for years because 2.4 has been the release branch for years (2007) and there has been very little 2.5 development that necessitates a 2.5 release. Last I checked the roadmap for 2.5, it hadn't been updated in ages, and there has been very little development of the features listed on it in any case.
People have been mentioning a switch to RE25 now and then, but does this mean Re25 is not happening soon anyway? Even if it does though, I suspect it'll be a while before RE25 reaches Stable level. So these RE24 vs master diffs will still be sitting there in the repo.
--On Tuesday, January 31, 2012 11:59 PM +0100 Hallvard Breien Furuseth h.b.furuseth@usit.uio.no wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, January 31, 2012 12:11 PM +0100 Hallvard Breien Furuseth h.b.furuseth@usit.uio.no wrote:
I think we should leave the current CVS-style branching model andmake 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.
Abandonware? What are you talking about? Both of those, AFAIK, are 2.5 features, which is why they haven't been released.
Aha, I hadn't caught that. I remember slapmodify (or the companion LDIF api?) is buggy and had the distinct impression that this is well known. I may have been thinking of contrib:ucn rather than contrib:vc. <grepping...> a note from hyc @ irc: "ITSs against it [usn] should be discarded since we already know it's not meant to be used". WTF...
Anyway, why can't slapmodify, <libldif replacement>, vc be finished and go in RE24? contrib/ stuff does not get in the way, but companion libldap/slapd differences beween master and RE24 do. They get in the way of testing, cherry-picking etc.
There's a point at which a release tree is "feature frozen", and generally, new features are not to get added into it, although we certainly break this rule fairly regularly (delta-syncrepl, back-mdb both immediately come to mind). But if we pulled everything we've done in the master branch to RE24, then we'd have nothing to show for RE25 so far. ;)
In any case, whether or not to pull those things into RE24 from the master repository is generally Howard's call as Chief Architect.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Hallvard Breien Furuseth wrote:
Aha, I hadn't caught that. I remember slapmodify (or the companion LDIF api?) is buggy and had the distinct impression that this is well known. I may have been thinking of contrib:ucn rather than contrib:vc. <grepping...> a note from hyc @ irc: "ITSs against it [usn] should be discarded since we already know it's not meant to be used". WTF...
The usn overlay was committed as-is but was not completed; at the time of writing we had no complete spec for usn behavior. I think complete specs have turned up since then, but it hasn't been a high enough priority for me to go back and finish it, and no one else has bothered to look at completing it.
Oh well, sorry about the abandonware stuff. Getting back to the more prosaic subject, I do think it'd be better to do more coding in a branch off RE24 than off master - except stuff intended for RE25 in the first place. Or code which starts intended for RE24 but ends up waiting for RE25, which is maybe what I remember as abandonware:-(
Once everything intended for RE24 is in the RE24 branch, we can merge that branch (or its descendant maintenance branch) to master but not the other way around, and the code can hopefully be merged instead of cherry-picked into RE24.
Also holding the door open for 'hotfix' branches should help, and killing old CVS branches, like mentioned in the original mail.
On Feb 1, 2012, at 9:26 AM, Hallvard B Furuseth wrote:
Oh well, sorry about the abandonware stuff. Getting back to the more prosaic subject,
First, whether to use a back-port or a forward-port model has nothing to do with git(1) v. cvs(1). Both revision control systems support both models.
Back-port is basically: apply to trunk and back port to releases as needed. (If a bug is only in X and older releases, then apply to X branch and back port from there.) You never forward port in the back-port model.
Forward-port is any model which requires forward porting. There's variants here, some of which also require back-porting.
I do think it'd be better to do more coding in a branch off RE24 than off master - except stuff intended for RE25 in the first place.
The back-port model is generally better in my opinion. It effectively eliminates the risk of regression that is high in any forward port model.
Your suggestion will lead to regressions and hence, IMO, bad. It's also messy, time consuming, and error prone from a release engineering stand-point.
It is important for the release engineer to control what goes into release branches. If you code off the release branch, then the release engineer has to be involved early and frequently. It is far easier to do "batched" release engineering but forward porting models are incompatible with "batched" release engineering.
As far as branching is concerned, my only recommendation is to avoid 'feature' specific development branches in the main repo. Instead, personal (but shared) repos can be used. If appropriate, we can even host these on openldap.org. But even these don't really cause any release engineering issue and hence shouldn't be a big concern. It might be nice to archive these (and the old non-release CVS branches) once they are no longer in use, just to reduce the noise. Personally, I prefer not to archive old release branches (as I find them useful long after they are closed).
But, in general, I advocate leaving well enough alone... especially if it not helping our release engineers (or worse, will cause release engineering pain).
-- Kurt
Or code which starts intended for RE24 but ends up waiting for RE25, which is maybe what I remember as abandonware:-(
Once everything intended for RE24 is in the RE24 branch, we can merge that branch (or its descendant maintenance branch) to master but not the other way around, and the code can hopefully be merged instead of cherry-picked into RE24.
Also holding the door open for 'hotfix' branches should help, and killing old CVS branches, like mentioned in the original mail.
-- Hallvard
On Fri, 10 Feb 2012 05:18:58 -0800, Kurt Zeilenga kurt@OpenLDAP.org wrote:
On Feb 1, 2012, at 9:26 AM, Hallvard B Furuseth wrote:
Oh well, sorry about the abandonware stuff. Getting back to the more prosaic subject,
First, whether to use a back-port or a forward-port model has nothing to do with git(1) v. cvs(1). Both revision control systems support both models.
Yesno. The difference is partly that Git supports consistent branches, but more that it suppors sane merges. Which makes it more of a win than in CVS to arrange things so we can use merge or fast-forward instead of cherry-picking.
(...)
I do think it'd be better to do more coding in a branch off RE24 than off master - except stuff intended for RE25 in the first place.
The back-port model is generally better in my opinion. It effectively eliminates the risk of regression that is high in any forward port model.
If you say so, but why port to/from master instead of a branch off RE24? Porting between more different code bases introduces more risk. We don't have an active RE25 to port back from or forward to. Currently master is just RE24 + some code which will someday in the future be used after cleaning it up and maybe still porting it (and other things) to whatever RE25 will look like.
Your suggestion will lead to regressions and hence, IMO, bad. It's also messy, time consuming, and error prone from a release engineering stand-point.
It is important for the release engineer to control what goes into release branches. If you code off the release branch, then the release engineer has to be involved early and frequently.
Er, I may have left out the RE24 branch itself:-( I tried to keep excessive branches out of the suggestion, that got a bit too far.
I'd certainly prefer to code in a branch off RE24 and not in RE24 itself. An in any case to revert stuff which gets into that branch but can not be released (yet). Or at least wrap that in #ifdef LDAP_DEVEL.
Then the release engineer can hopefully just fast-forward or merge into RE24, but he doesn't have to. And we'd hopefully learn discipline enough to not just throw half-finished stuff into it. That's for the current master branch.
I don't see what's messy about that. It'd be messy if people put code there just "get more eyes on it" as in master today, then this branch would turn into just what master has been at times: A branch with a bunch of as-yet unreleased code which someone someday might finish. And having two different branches like that would indeed be messier.
As far as branching is concerned, my only recommendation is to avoid 'feature' > specific development branches in the main repo. Instead, personal (but shared) > repos can be used. If appropriate, we can even host these on openldap.org.
IIRC there's always been a fair amount of code in master just sitting there unfinished. Commit messages like "this is a preliminary code drop", and then maybe sometime later it gets finished. If people will be content to keep such things in separate repositories, fine. That's a lot easier with Git than with CVS.
But if the author wants to push it to the main repo to get more eyes on testers for the code, which IIRC was one reason for keeping the current arrangement, then I'd much rather see it in a feature branch.
(Also I assumed merging feature branches would also tend to be easier than porting between branches, but I haven't tried that myself yet.)
In any case, two branches (maint and hotfix) off RE24 is the main thing I'd like, feature branches seem less important.
(...) It might be nice to archive these (and the old non-release CVS branches) once they are no longer in use, just to reduce the noise. Personally, I prefer not to archive old release branches (as I find them useful long after they are closed).
Renaming to refs/archive/<heads,tags>/* reduces the noise but still keeps them in the repo. I think git config --add remote.origin.fetch 'refs/archive/*:refs/archive/*' will get those symbols in addition to the rest.
But, in general, I advocate leaving well enough alone... especially if it not helping our release engineers (or worse, will cause release engineering pain).
Actually helping out with that was one thing I hoped this would do.
On Feb 10, 2012, at 7:18 AM, Hallvard B Furuseth wrote:
Then the release engineer can hopefully just fast-forward or merge into RE24, but he doesn't have to.
Bullshit. If we were to follow your suggestion, the release engineer will have not only deal with patches nominated for review, but deal with all patches, reverting those not ready for release... and then, if subsequently nominated/approved for release, cherry-pick them again onto the branch. Or other such mucking. It's not 'just' fast-forward or merge.
And we'd hopefully learn discipline enough to not just throw half-finished stuff into it.
That's likely never to happen.
Developers need a branch to collective play with stuff not yet ready for release.
That's for the current master branch.
Master is currently that playground (unless the patch is far too playful, in which case they should do it in another repo).
I don't see what's messy about that. It'd be messy if people put code there just "get more eyes on it" as in master today, then this branch would turn into just what master has been at times: A branch with a bunch of as-yet unreleased code which someone someday might finish. And having two different branches like that would indeed be messier.
You are not going to magically change the development culture of any project overnight.
As far as branching is concerned, my only recommendation is to avoid 'feature' > specific development branches in the main repo. Instead, personal (but shared) > repos can be used. If appropriate, we can even host these on openldap.org.
IIRC there's always been a fair amount of code in master just sitting there unfinished. Commit messages like "this is a preliminary code drop", and then maybe sometime later it gets finished. If people will be content to keep such things in separate repositories, fine. That's a lot easier with Git than with CVS.
While git certainly makes it easier for more playful patches to be kept outside the main repo, we've otherwise tried to keep really playful stuff out of the master... whether by just saying 'no' or putting it on dev branches.
While git makes it easier for developers to play in smaller groups. and that reduce the need to dev branches, I don't switching to git(1) as having changed our culture one bit. Our developers still want a common place to put changes intended for non-immediate (or non-next minor) release. That place is the master branch.
But if the author wants to push it to the main repo to get more eyes on testers for the code, which IIRC was one reason for keeping the current arrangement, then I'd much rather see it in a feature branch.
Things also get pushed onto master so the community as a whole can further develop/test the changes.
git(1) can lead one to many different islands of code. While that has some advantages at times, it also has its draw backs.
In general, I think our approach has been balanced and should remain balanced. Use islands where it makes sense, use main repo when it makes sense, use master in main repo when it makes sense.
(Also I assumed merging feature branches would also tend to be easier than porting between branches, but I haven't tried that myself yet.)
Merging, in my view, is a form of porting.
In any case, two branches (maint and hotfix) off RE24 is the main thing I'd like, feature branches seem less important.
We've traditionally hot fixed on the latest branch the bug exists on. If the bug is on RE24 but not master, you fix on RE24 directly. There's no need for a 'hotfix branches'.
(...) It might be nice to archive these (and the old non-release CVS branches) once they are no longer in use, just to reduce the noise. Personally, I prefer not to archive old release branches (as I find them useful long after they are closed).
Renaming to refs/archive/<heads,tags>/* reduces the noise but still keeps them in the repo. I think git config --add remote.origin.fetch 'refs/archive/*:refs/archive/*' will get those symbols in addition to the rest.
But, in general, I advocate leaving well enough alone... especially if it not helping our release engineers (or worse, will cause release engineering pain).
Actually helping out with that was one thing I hoped this would do.
I don't see how your suggestions help release engineers, especially in absence of change of development culture or 'discipline'.
-- Hallvard
-
Hallvard B Furuseth -
Hallvard Breien Furuseth
-
Howard Chu -
Kurt Zeilenga -
Quanah Gibson-Mount