Update on Gerrit deployment
andy.green at linaro.org
Sat Aug 27 13:29:19 UTC 2011
On 08/27/2011 02:15 AM, Somebody in the thread at some point said:
>> How well what are basically externally generated and managed kernels will
>> fit into Gerrit flow is something I don't really understand. But I don't
>> think it will be as simple as the case where the kernel is a history tree
>> managed entirely through gerrit flow and everyone is happy.
> My main issue with stgit is that its only useful for a single person
Stgit is a nice adjunct to git that lets you juggle and reorder
patchsets easily; gerrit seems to be some kind of slashcode 0.01 one
could knock up in a few days using LAMP where patches are the article
and get voted on by folks. They are unrelated.
> to manage a patchset on top of a history tree. When many people then
> rely on that tree, something like stgit makes it hard for them to deal
> since the history is always changing. Now the really cool thing about
That's nothing to do with stgit but "rebase flow". You can very well do
rebases generally with pure git.
Android tree is just one of the things we're looking after, it is very
convenient for us to have a rebase flow that let's us focuses on one
intermediate vanilla enabled tree, so we do work once for that common
basis, that is then rebased against the various bases that people want
including Android. I use stgit-based scripts internally to manage that
but none of our output exposes that, it's all pure normal git.
> Gerrit is that it doesn't care if the tree has been rebased. It will
> just try and merge the changeset on top of the current tree, whatever
> the history so in that case Gerrit is actually enabling developers to
> work with trees that are continually rebased (like the linux kernel).
Linus' tree is a history tree, fwiw.
For kernel, gerrit users even generating the patches to propose requires
git. So gerrit is just a sort of secondary 'social' option on top of
git, which remains mandatory.
I want to respect people's contribution, but I don't see how external
voting on patches is going to help me: either it fits at my tree's
level, has a use and doesn't conflict in which case I'll take it, or
it's not going to work out for me and it won't work out any better if
one or more people clicked +1 on it.
I don't think we can dispense with one person attempting to understand
what the patches are and what they buy us, what their future is and if
they want them which trees they go on, etc, by a kind of
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
More information about the linaro-dev