On 07:30 Tue 21 Jun , Øyvind Harboe wrote: > 2011/6/21 Jon Povey <jon.po...@racelogic.co.uk>: > > Øyvind Harboe wrote: > >> I am struggling a bit following the above, but I think we agree: > >> > >> - development goes on in master like it always has done > >> - you create a fork at the openocd mirror and create a > >> release branch there. > >> You pick whatever you want from the master branch or whatever patches > >> posted that you think should go in and generally run the > >> release cycle. > >> - once you're done with the release, I pull it from you and push it to > >> the official openocd repository. > > > > Just my 2 cents: > > > > This sounds like a bad idea to me if I understand right. It means the > > release versions will always be in branches that either do, or don't, > > get merged back into master. > > > > If they don't get merged back in, then future releases are not direct > > descendants of older releases. That is not good for history review or > > trying to understand where a bug comes in, you can't bisect between > > version n and n+1. > > > > If they do get merged in then you end up with messy history and again > > difficult to bisect and isolate problems if something breaks when > > merging in the release version. > > > > I would suggest better would be to do all releases from master in a > > linear fashion, going into feature freeze as needed. At the close of > > a merge window new development would continue on another branch, > > "next" or "staging" or whatever. After tagging and releasing, the > > development branch would be rebased onto the master, giving a linear > > history. > > > > I think this is more or less how other projects including Linux do it. > > It takes a bit more thought and familiarity with git but results in > > a much cleaner more usable history. > > I think you raise some good points. > > After some consideration, I've changed my view to that the > release manager should have git access and that the master > branch developers *should* follow the release managers > marching orders and that we follow the cycle Jean-Christophe > outlined... I think perhaps that 2-4 releases / year would > be plenty for OpenOCD though. 4 releases / year is a good plan
I just send the first rc for now I put on my personal server The best way to do is to choose one git tree as the master git then each maintainer will have their one git tree too where they manage it how they want. They send me pull request for the master or the next depending on the merge windows and the type of patch this is basicly the linux, barebox work flow Best Regards, J. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
