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
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
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
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
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
> (...) 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'.