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
isithotornot.linaro.org.
-Andy
--
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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
