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.