I realise this reply is academic; I'm happy to accept the decision. For the record though...
Michael Hope <michael.h...@linaro.org> writes: > 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. Maybe this is just me, but the way I tend to work with bug-fix "feature" branches is to do the work locally (as I would with any other VCS), then create and publish the branch once I've tested everything and am ready for the changes to be reviewed. I think that publishing the branch in an incomplete state would increase the amount of work for me, and might also increase the noise for everyone else. With that way of working, sending a patch is just as public as creating a feature branch. > 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. But does anyone actually pick up Linaro GCC feature branches like that in practice, other than to merge them? And is it significantly easier than applying patches? My concern was that, again with my way of working, the process is: 1) develop fix 2) branch trunk (creating a whole new gcc source tree, so quite slow) 3) apply fix to new branch, with ChangeLog entry 4) publish new branch in laucnhpad 5) wait for branch to be processed by launchpad (only a few minutes, nothing major) 6) ask for a review 7) merge to trunk (with the inevitable ChangeLog merge failure that you mentioned). whereas the upstream way would be: 1) develop fix 2) ask for a review, attaching patch 3) apply patch to trunk, with ChangeLog entry The upstream way feels much simpler, and avoids the merge failure hassle. > Short story is that we have a better tool than svn, so feature > branches may make some use cases overall easier and more transparent. Well, as you say, the size of GCC and its history is pushing the limits of bzr a bit. For bug-fixing and committing, I actually find quilt+svn to be a fair bit more productive than bzr, and that's even with Andrew doing the heavy work on merging. I hope this doesn't sound like a grouch. It's certainly not meant to be. I just wanted to clear up what I meant. Like I say, I happily accept the decision. Richard _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
