Re: OpenLDAP 2.5

[Kurt Zeilenga <Kurt@OpenLDAP.org>]

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@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/