On 18 May 2011 13:07, Linus Walleij <linus.wall...@linaro.org> wrote:
> 2011/5/16 Paul Sokolovsky <paul.sokolov...@linaro.org>: > > > You expressed concern that Gerrit is not too flexible for working with > > multiple topic branches, in particular, that it enforces work > > against single (master) branch (as far as I understood). > > It was mainly me blathering about Gerrit in that session so don't > go after Arnd... > > I take a step back: there is nothing technical wrong with > Gerrit really, the problem is how it is used. > > And the problem is that Gerrit is often used (also by Google) > as a one-stop shop for integration. > > This means: you don't have what the kernel developers refer > to as topic branches. Instead, in the Google case, look for > example here: > > http://android.git.kernel.org/?p=kernel/experimental.git;a=summary > (...) > 4 months ago android-goldfish-2.6.35 > 7 months ago android-msm-2.6.35-wip > 8 months ago linux-tegra-2.6.36-wip > 10 months ago android-2.6.34-test2 > > These are indeed branches, but *what* is the topic > actually? > > Well, it turs out the topic is: "branch to rebase an big > whole shebang mega-patchset on top of a new kernel > upstream realease". > > That's not what kernel developers mean by "topic branch". > which is for example: > http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=summary > > With examples like this it is not strange that Gerrit is > used as it is in companies doing Android development. > > 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. > On most companies where I know the details, nobody > even has a clue what an octopus merge is. Eevrything > is integrated in Gerrit directly, 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. /Patrik > > So: Gerrit is indeed a good review system and has the > ability to use (topic) branches. But the examples from > companies like Google are not very good models of > what to do with them. > > Now there may be a reason why everything is still > integrated on a single branch, and that is > cross-subsystem dependency hell. If all drivers you > develop are cross-dependent on other drivers, you > end up in this place, such as you want to develop a > driver for I2C peripheral X but you don't have a driver > for the I2C bus yet (and a hundre times more complex > examples). What you need to do in that case is > to create new topic branch based on top of the > i2c-driver topic branch and so on, and then you have > to use just git, using Gerrit at the same time will > make it necessary to add/remove/rebase branches at > neckbreaking speed. If you just use a singe branch > the integration seems simpler to the organization. > > Yours, > Linus Walleij > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
