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. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
