Update on Gerrit deployment
zach.pfeffer at linaro.org
Fri Aug 26 18:15:46 UTC 2011
On 26 August 2011 00:04, Andy Green <andy.green at linaro.org> wrote:
> On 08/26/2011 12:12 AM, Somebody in the thread at some point said:
>>> 1. Set up branch policy (naming, etc.) and enforce it on Gerrit level.
>>> This may require revamping branching in other toolchain/* components
>>> (upstreamed not from AOSP), but in the end we'll get really robust
>>> development setup.
>> Agreed. One big thing that we need to work on is how we're going to
>> handle kernel upgrades - I think some special branch-naming may be
>> part of this solution.
>>> 2. Turn off review bypass option which was available during transition
>>> process. I guess Android team if comfortable by now with new process
>>> (there're more than 80 patches passed thru review by now!), so once
>>> 11.08 release is out, it would be good time to do that.
>> +1 for most. I think the only thing we have to watch out for is kernel
>> maintainers needing to push big updates out-of-band.
> Special case of that is going to be rebase branches as opposed to history
> ones, where 'disruptive' changes are going to be normal.
> 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.
I think it can be simple as long as we lay it out. The general plan would be:
We track a kernel tree branch that's considered tip. We pull from that
via repo and do builds etc.
That tree is manged by Gerrit with a maintainer backdoor.
A Gerrit change makes it into the tree after its been reviewed,
approved and passes regression.
The maintainer approves the change.
The maintainer has the ability to reorder, rebase or do what ever they
want outside of Gerrit. Their only extra duty is to ensure that
patches that have been accepted are now in the tree. Anything that
hasn't been accepted would just follow the normal flow since each
change is merged against the current state of the tree.
My main issue with stgit is that its only useful for a single person
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
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).
> 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