On Mon, 29 Aug 2011 08:08:17 -0500 Zach Pfeffer <zach.pfef...@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). > 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/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
