On Thu, Mar 10, 2011 at 11:51 PM, Richard Sandiford <richard.sandif...@linaro.org> wrote: > On 9 March 2011 20:56, Michael Hope <michael.h...@linaro.org> wrote: >> We currently use a feature branch / merge request / merge / test / >> push approach in gcc-linaro. This works fine for a reasonable cost >> but can mean that patches sit unreviewed and unmerged for up to a >> month. Ramana, Andrew, and I had a talk about this earlier in the >> week and I've written up the ideas here: >> https://wiki.linaro.org/MichaelHope/Sandbox/ReviewThoughts >> >> We're a bit unique as gcc-linaro started from a mature base, running >> the testsuite takes days, and the product is so big that bzr takes a >> long time to work on it. >> >> If you have experience in running a master branch or ideas on >> continious integration please have a read. > > FWIW, I like "on trunk", because it's closer to what we do upstream. > But for that case, is there any need for a "published" feature > branch at all? Is there a problem with committing local changes > (or merging a local branch) directly to trunk?
Here's some use cases if we go with 'on trunk': 1. Obvious patch: commit directly 2. New work: gets reviewed upstream, then /could/ be committed directly. 3. Linaro specific fix: reviewed inside Linaro, then committed With (2) and (3) you need somewhere to do the work. It could live as uncommitted or unpushed work in your repo but this makes it a bit hidden and private. With (3) you need some way to share the work. This is done in (2) by sending a patch but I think a feature branch that someone can pick up would be nicer. Short story is that we have a better tool than svn, so feature branches may make some use cases overall easier and more transparent. -- Michael _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
