2011/5/19 Paul Sokolovsky <paul.sokolov...@linaro.org>: > 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.
True for any FOSS that comes out of Google, for kernel, BlueZ etc Google cannot really be considered upstream. And we were discussing the kernel here I believe. > 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. It's (2) >> 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. Yeah. >> These are indeed branches, but *what* is the topic >> actually? > > Well, yeah, they're release, not topic centered ;-). Yes and that is not how kernel development works. And what the Linaro organization, especially the landing teams, want to achieve is merging the code to Torvalds, which means clean cut topic that get pulled into mainline. >> 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. We are talking past each other here. The problem in the sessions I was to was about working with the kernel community, not managing Android integration. > 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. One does not exclude the other I believe. I also believe it is possible to make an exception for the kernel and other upstream projects, it's just a GIT after all, and it has a very clean cut API amd ABI. > But I agree that Gerrit doesn't immediately fit > with canonical kernel workflow, while its choice is almost fixed for > Android by upstream usage. Define the "canonical kernel workflow", what I'm talking about is the kernel community workflow. > 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. Gerrit handled topic branches, it's mainly about integration and how people are told to work. But mainly yes. Yours, Linus Walleij _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
