Linaro and common- tree
andy.green at linaro.org
Wed Oct 5 15:57:58 UTC 2011
Recently at Linaro we've started a new tree linaro-androidization-tracking,
which is pretty much "common-3.1" at the moment on 3.1-rc8 basis.
We have already been running a kernel tree tracking Linus HEAD since 2.6.39,
which has OMAP4 / Panda enablement stuff on top of Linus HEAD, so we have
some experience with the rough and tumble.
What we missed having was an "all year round" Androidization tree that we
could combine it with to casually create Android versions of the work we
were doing on Vanilla Linus HEAD basis. We used common-3.0 for that for a
while late in the kernel release cycle when it was tracking Linus HEAD
itself and that was great. But common-3.0 like the name suggests is really
a release tree, and it stops tracking at release, and a new one starts up
only late in the next kernel release cycle.
Actually, it would be a big advantage for many folks to not be doing their
Android kernel development on lagging releases, but by tracking Linus HEAD.
They would have access to latest stuff already and they don't have to think
about backport or later forwardport stuff to a new release, it's constantly
tracking HEAD and being adapted.
One side-effect of using this tracking methodology is if they want release
trees, they can just clone their tracking branch at the time Linus HEAD is
at a release point and bam, a hopefully fully working release tree is
there. Another very nice side-effect is they can do the bulk of the work
once on a Vanilla Linus HEAD basis, and get and Android version of that work
routinely by merging or rebasing in the Androidization tree - instead of
doing and validating work twice on separate Vanilla and Android trees.
So linaro-androidization-tracking is our attempt at that Linus HEAD
Androidization tree, moving it on regularly and fixing breakage as it
happens throughout the cycle. It's generic same as common-, it should be
usable for any arch or board to Androidize a vanilla kernel that is on the
same Linus HEAD basis just by merge or rebase action.
It seemed this effort might be interesting for the guys that make the
common- trees, since if there was a tracking Androidization tree, in fact
common- releases for release trees like common-3.1 would just naturally fall
out of it when Linus HEAD was at 3.1. So I'd be very happy to hear any
opinions about that.
Another side-issue is we are also looking at refactoring the Androidization
patchset into topic branches, at the moment they're kind of reflecting the
history that they were applied on plus or minus some munging around. So,
all the net core patches for example would be together in one series, then
all the wireless ones in a series on top of that, etc. It seems they would
be easier to maintain then, opinions on that approach are also welcome.
 TI have a tree on omapzoom where we got the patches from
(Apologies for any duplication, googlegroups needs mail sent from Google
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-dev