On 29 August 2011 08:22, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Mon, 29 Aug 2011 08:08:17 -0500 Zach Pfeffer zach.pfeffer@linaro.org wrote:
Now that we have an Android build for every board and Gerrit and LAVA I'd like to unify how we handle kernels for each so that we can work more efficiently, start to unify the kernels and provide a means for external Android users to start to improve these trees.
First, since we control the kernels that go into our Android builds I'd like to follow AOSP convention and have:
kernel/common.git (john's tree)
Correction: kernel/common is AOSP upstream, John's tree is kernel/linux-android .
kernel/imx53.git kernel/omap.git kernel/origen.git kernel/snowball.git
These looks ok and in line with existing AOSP's naming conventions.
(right now we have:
panda, beagle
<remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/jstultz/android" revision="linaro-android-3.0" remote="linaro-other"/>
panda-leb
<remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/andygreen/kernel-tilt" revision="tilt-jstultz-linaro-android-3.0" remote="linaro-other"/>
leb-snowball
<remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="bsp/st-ericsson/linux-3.0-android-ux500" revision="master" remote="linaro-other"/>
leb-origen
<remote name="linaro-other" fetch="git://git.linaro.org/"/> <project path="kernel" name="people/angus/linux-linaro-3.0" remote="linaro-other" revision="android"/>
leb-imx53
<remote fetch="git://git.linaro.org/" name="linaro-other"/> <project name="people/bernhardrosenkranzer/android-kernel-iMX53" path="kernel" remote="linaro-other" revision="3d981d9418c53e3e1a079582088121c641588791"/> )
I'd like these to be at git://android.git.linaro.org/. I'd like to not mirror.
Each tree would accept patches via Gerrit and be maintainable through standard git by the tree maintainers. This should allow upgrades to each, without needing to push all the upgrade patches through Gerrit.
Next, we'd like to point to a tip branch for each of these trees. This branch would be were development would be happening. Tracking tip is fundamental to continuous integration, if its broken then the primary job of everyone should be getting it going again. I'd like to suggest the branches be named the same and follow John's branch naming convention:
linaro-android-3.0...etc
Lastly, I'd like to request (and we may be able to automate this once all the kernels are co-located) that once a pinned-manifest.xml comes out, referencing a specific sha1, I'd like to lay a tag on that sha so it sticks around.
It's not enough if you still want to refer to it via SHA, due to repo peculiarities. It should be also reachable from one of the live branches (so, instead of a tag, a branch can be created right away).
That sounds good. Perhaps we should lay down the branch across every git on a successful build. It could be like a cursor that would track the latest. We'd still do the pinned-manifest.xml but users would be able to
Its better to tag after the fact because it saves having to do another build/test/qa cycle and will ensure that our pinned-manifest.xml continue to work.
I suspect a few growing pains, but I think this is going to be great. Once the kernels are co-located we should be able to look at Gerrit extensions that allow easier upstream patch submission and tracking. We should also be able to more easily refactor things. Using the Gerrit flow and extending it to support Android upstreaming is exactly the thing Linaro was built for. Since Gerrit is such an integral part of Android development, extensions to allow patch propagation would allow a lot of the good work to flow back into the mainline kernel.
-Zach
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog