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

Reply via email to