Update on Gerrit deployment

Andy Green 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://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

More information about the linaro-dev mailing list