2011/5/18 Patrik Ryd <patrik....@linaro.org>: > On 18 May 2011 13:07, Linus Walleij <linus.wall...@linaro.org> wrote: >> I think it basically boils down to the fact that a single >> Gerrit branch is seen as "the place to integrate", whereas >> in kernel terms, you should integrate a single topic >> (such as "i2c updates", "boardfiles", "regulators" etc) >> and the system integrator should use plain git (no web >> interface!) to integrate the result with an octopus merge >> to produce a complete product. The result of the >> octopus merge should be frozen, i.e. it is not allowed >> to be used as a starting point for further development. > > If we have gerrit, build servers and test farm set up and we have managed to > get the whole continuous integration process going is there the anything > that prevents that we push to a topic branch for review and that the first > step before the build starts it to do a merge of all topic branches for the > kernel.
Well occasionally there are merge conflicts. Which need to be resolved manually :-P But there is nothing stopping you from testing each topic branch in isolation I guess. The problem appears when you want to continously test "the whole product", i.e. a mergedown of all topic branches. So in this particular case the agile programming axiom to always have a running build every night clashes with the idea of working in isolated topic branches - the former really benefit from all integration being done on a single branch. >> One reason is that I think you have to configure Gerrit >> for each new branch you create or delete, and that >> means a real bad fit with the kernel model of quickly >> creating/deleting and rebasing branches. > > Branches are "configured" in the same way as in git. :) You do a git push to > the branch you want to create. The difference is that when you do your git > push gerrit will check if you have the permission to create branches. Yes I was completely wrong on this, Gerrit is really flexible with branches, Ian Kumlien also taught me this... Thanks, Linus Walleij _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
