2011/5/18 Patrik Ryd patrik.ryd@linaro.org:
On 18 May 2011 13:07, Linus Walleij linus.walleij@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