Update on Gerrit deployment
johnstul at us.ibm.com
Sat Aug 27 21:20:44 UTC 2011
On Sat, 2011-08-27 at 21:29 +0800, Andy Green wrote:
> On 08/27/2011 02:15 AM, Somebody in the thread at some point said:
> > 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
I think you're greatly mis-characterizing what gerrit does. *No one*
maintains a code tree like a democracy.
I too suspect the voting (which is really just review logging, something
most mature projects require and use, be it "Acked-by" lines or
whatever) won't be of much use to us, as we're still fairly loose with
our change management and we trust tree maintainers.
As a maintainer, I think the formal submission tracking (ie: here are
changes submitted that have not yet been included) is really the part
that is potentially valuable to us. It makes sure the work folks submit
doesn't just get lost in churn and busy crunches.
Additionally, a more minor perk is that it allows series of patches to
be merged without the manual plucking from your inbox, saving to files,
copying them to my git tree server, and then git am'ing them in.
Now, again, I'm not a fan of gerrit. And outside of the Android work, I
*really* don't see it providing any value to Linaro (personally I'd like
to see a tool more like patchworks integrated with git that provides the
same benefits as above).
But I've got an open mind and am willing to try it out and figure out a
workflow. I suspect for me it really won't be anything other then a
different location to "git push" to.
If we do actually start to see an inflow of kernel patches through
gerrit, we can see how that workflow functions and have a concrete
discussion on pros and cons (worse case, I git cherry pick the commits I
like to my tree and push it out, or we can ask to see if gerrit can be
configured to mail patches to us). But I really really doubt this will
be a common thing.
Again, I've volunteered to lead the way on the kernel side in this trial
run, and (while there have been some initial configuration hiccups) it
really has been almost zero overhead/impact to my workflow so far.
(And forgive me for posting and running here, as I'm out of the office
for the next two weeks - including Linux Plumbers, so I may not respond
to further replies for some time. So feel free to have the last word. :)
More information about the linaro-dev