On 18 May 2011 13:07, Linus Walleij linus.walleij@linaro.org wrote:
2011/5/16 Paul Sokolovsky paul.sokolovsky@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%3Ba=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%3Ba=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