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