On Jan 13, 2010, at 1:24 PM, Howard Chu wrote:
Simon Wilkinson wrote:
>
> On 5 Jan 2010, at 18:33, Quanah Gibson-Mount wrote:
>
>> --On Tuesday, December 22, 2009 7:40 PM -0800 Howard Chu <hyc(a)symas.com
>>> wrote:
>>
>>> With 2.4.21 out, and hopefully stable enough to promote to the next
>>> Stable release, it's time to feature-freeze 2.4 and prepare for the
>>> 2.5
>>> branch. As I already announced to the OpenLDAP-Committers, we're also
>>> planning to switch from CVS to GIT in mid-January. Commits for 2.5
>>> will
>>> begin after we've settled into GIT.
>>
>> Yeah! One question from the RE side, is how to best handle 2.4
>> fixes with HEAD getting further & further apart.
>
> You also want to consider how git's tools for branching and merging
> fit together. We went through this with OpenAFS last year, guided by
> some very helpful conversations with Shawn Pearce. Basically, the
> fundamental question is whether you want a merge based workflow, one
> based around cherry-picks, or some hybrid version of the two.
I think it would be good to maintain a central repository for trunk and each release
branch, and cherry-pick patches over (possibly with back porting).
Individual developers can more easily share work between them, but there should still be a
central place to get trunk and release branches.
So the workflow would, from a project perspective, be the same with git. Committers would
'push' to trunk, release engineers would cherry pick and commit onto release
branches.
>
> If you have a merge based workflow, then the model is that you make
> that change on a branch, and then merge that branch into the head.
> OpenAFS (and OpenLDAP, by the sounds of things) had a model where we
> committed to HEAD, and then 'pulled-up' to the relevant branches.
s/pulled-up/cherry-picked (with back porting as needed)/
> You
> can't do that with a git merge,
Yes you can. We do in at my day job all the time.
> because the commit on HEAD includes
> the history of everything else on head, which you definitely don't
> want to pull into the branch.
Individuals commit on their own local clones, and use 'git push' onto the
project's trunk. Release engineers can then cherry-pick the trunk patch onto their
local clone of the release branch and push to the project's release branch.
> So, we ended up deciding to cherry-pick
> pullups. This makes it harder to tell whether we've missed anything
> that should be pulled up, but "git cherry" helps ease that pain, and
> it means we keep our existing workflow.
What I use to do when I was the release engineer is to have a "merge-point" tag
on trunk (per release branch) to track what changes I've merged into release branch.
When I cherry picked everything that was to be cherry picked over, I'd move the
merge-point forward to HEAD. That way when I came back weeks or months latter, I knew
exactly where I left off.
One can do the same in git.
Also important is to diff trunk and the release branch to make sure differences are what
you expect them to be. This of course is more feasible for the trunk and the current
release, less so for the release your phasing out. But with the release your phasing out,
you ought to be quite selective in what you pull over.
>
> I'd also strongly recommend that you take a look at Shawn's
"gerrit"
> tool. This provides a code review tool for patch submission, and
> hugely simplifies the process of controlling push access to a git
> tree, and reviewing the changes that you accept.
We've never had any restrictions on commits. We always done design review pre commit
and peer review post commit.
Since we push to trunk first, there is little need to have "sign-offs" or
restrictions.
And we've never had the repo enforce who can commit to release branches. We could
have done this with CVS but figured it was easier just to tell folks what they are or are
not allowed to do and deal with violations after the fact (e.g., slap wrist).
>
> I'm happy to talk to you about OpenAFS's experiences in all of this,
> if you'd like more details.
Absolutely, thanks for the offer. Up till now my use of git has been extremely
basic. It wouldn't bother me too much to continue the CVS-style workflow we've
had,
I would strong recommend that one should not change both repo software and engineering
process at the same time. First, switch repo software. Learn it. Then, if consider
changes the workflow.
but if there are better ways that involve less manual labor, we
certainly
want to know.
Whose labor? Release engineer is always going to be tedious (sorry). Certainly there
are things that can make release engineers life easier, but I'd focus on those which
don't shift the burden elsewhere. In particular, I think it would be unwise to make
development processes in general more tedious.
Also, if you are going to study good and bad releasing engineering practices of open
source projects, I suggest looking at FreeBSD as a success story. OpenLDAP's
processes are in fact based (a decade ago) upon FreeBSD processes.
(Though frankly, the fact that git is faster and works from a
complete local
repo was convincing enough for me. Being able to perform local commits to save
and backtrack my work-in-progress without requiring network access is already
a huge gain.)
The thing I think git really helps with is collaborative development. It much easier for
two developers to share work between them in preparation for submitting something to the
project.
-- Kurt
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/