On Saturday 21 May 2011, Paul Sokolovsky wrote:
On Sat, 21 May 2011 09:23:28 +0200 Linus Walleij linus.walleij@linaro.org wrote:
2011/5/19 Paul Sokolovsky paul.sokolovsky@linaro.org:
I look at Gerrit from Linaro Android perspective, and there's of course one good reason to use it in this scenario: it's what the upstream uses, so good it or bad, if we want to work with upstrean, we'll need to eat Google's own dogfood.
True for any FOSS that comes out of Google, for kernel, BlueZ etc Google cannot really be considered upstream. And we were discussing the kernel here I believe.
No, sorry for the confusion and not making this clear - I wrote the original mail as a follow-up to "Android Code Review" session, https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-code-... http://summit.linaro.org/uds-o/meeting/linaro-android-o-code-review/ , where Arnd expression concerns which were discussed. I look at Gerrit from viewpoint of Android/Infrastructure team, and collect and appreciate feedback and usecases from wider audience.
Sorry for the late follow-up, too many things kept coming up at once in the last few weeks. Here is what I had in mind, tell me if I should add this to the blueprint or how else you want to proceed.
== User Stories ==
Karl is a developer for a kernel driver and works within a project using Gerrit. Every work item he does results in a patch that he sends for review to his subsystem maintainer. He marks his work items as done once the patch has been accepted into the subsystem branch.
Eva is Karl's subsystem maintainer and all of his patches that she accepts are applied to the branch that she maintains for that kind of device driver. She also maintains branches for a small set of other subsystems. Since her main target is to integrate the work upstream, the separation between the branches is based on how her kernel upstream maintainers work. When Eva considers one branch ready for upstream submission, she rebases the branches as necessary to avoid conflicts and she sometimes folds patches in order to be acceptable.
Harald is a release maintainer in the same project. He maintains a master branch with all the work done by subsystem maintainers such as Eva, and he pulls in changes from all their branches into his master branch. Harald sometimes gets upset when Eva has to rebase a branch, but he accepts that as part of his daily work. After a product release, Harald archives his branch and starts a new branch based on the latest upstream kernel and the subsystem branches that have not yet been merged into that version.
== Missing Pieces ==
* Gerrit apparently does not have a good way to automatically integrate work from multiple branches. Ideally, manual interaction should only be necessary when branches don't merge cleanly, or when they have been rebased.
* Rebases don't fit the Gerrit model of always just adding patches on top. However, in order to work with upstream, it is often necessary to change main design choices throughout a patch series, not just by adding changes at the end of the series.
Arnd