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;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