On Tue, Jun 28, 2011 at 1:56 PM, Øyvind Harboe <oyvind.har...@zylin.com> wrote: > On Tue, Jun 28, 2011 at 7:30 PM, Jean-Christophe PLAGNIOL-VILLARD > <plagn...@jcrosoft.com> wrote: >> On 19:39 Tue 28 Jun , Øyvind Harboe wrote: >>> > but now all the maintainer will have their own fork/repository >>> > as done in the kernel >>> >>> Right. And you will pull & merge from us and push the result to the >>> master branch? >> exactly > > I'd have some reservations about only one person having write > access, but not particularly the way of working. Call me old fashioned. > It's not old fashioned. It's just how Linux works. Other projects have different release management processes. One kind of releasing process I know is (briefly):
Multiple people have write access to the master branch. When the release manager think it's a good time to do a release, he/she will create a branch for that release. After that branch has been created, all new features will only go to the master branch. All fixes will go to the master branch as well as to the release branch if they are needed there. Developers can cherry-pick their fix from master to the release branch under approval of release manager, or the release manager can do the cherry-picking. When the release branch comes to a good status, the release manager roll out a release. Several very large projects use this kind of process. It works well. Btw, I don't think it's a good idea to put release branch in a separate git repository. Jie _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
