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 isithotornot.linaro.org.
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. :)
thanks -john