On Jan 13, 2010, at 1:24 PM, Howard Chu wrote: 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. s/pulled-up/cherry-picked (with back porting as needed)/ Yes you can. We do in at my day job all the time. 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. 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. 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 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. 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. 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