Hello Linus, On Wed, 18 May 2011 13:07:50 +0200 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... Well, maybe I missed something, but somehow I have a feeling that Gerrit was discussed at two (or more) sessions. I look at Gerrit from Linaro Android perspective, and there's of course one good reason to use it in this scenario: it's what the upstream uses, so good it or bad, if we want to work with upstrean, we'll need to eat Google's own dogfood. But yet at LDS I got an idea that there was talk/thinking about using Gerrit for more than Android, and now I looked thru Kernel Track session (pity I couldn't follow it closer) and saw that's the case. In either case, concerns expressed about Gerrit could have been either: 1. Gerrit workflow is hardcoded to be too rigid and inflexible. or 2. Typical Gerrit workflow is not well suited, flexible, or advanced for multi-(topic)-branch and other workflow patterns. > > I take a step back: there is nothing technical wrong with > Gerrit really, the problem is how it is used. Ok, so it seems that it's point 2 above after all. > > 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, yeah, they're release, not topic centered ;-). > > 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. True, but there're also (good?) reasons for that. For Android, kernel is, while big and important, just one of a hundred of components. And not even primary development focus, which otherwise would be platform middleware and user apps - again, hundreds of components, so if guys used topic branches (for each of them), they would be drowned in them. So, instead there're release-based branches, and Gerrit which appears to help to deal with all of multitude of changes to all those components. > > 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. > > 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. Well, so bottom line of this, as far as I see it, is: Gerrit is de facto tool for Android, and for Linaro Android we'd like to be sure that it supports more flexible/advanced approach than which is seen typically in Android shops. It's also nice idea to select single official Linaro git review tool. But I agree that Gerrit doesn't immediately fit with canonical kernel workflow, while its choice is almost fixed for Android by upstream usage. So, we either would need to experiment with using Gerrit in news ways, for example, like you suggest, set up separate a Gerrit instance for each "project" (each topic branch can be see as such), or... just keep our options open and don't fix on Gerrit as pan-Linaro panacea. > 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 -- Best Regards, Paul _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
