On 26 August 2011 00:04, Andy Green <andy.gr...@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 > > -- > 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
