On 29 August 2011 08:22, Paul Sokolovsky <paul.sokolov...@linaro.org> wrote:
> 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).

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/#!/linaroorg - http://www.linaro.org/linaro-blog
>

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to