Hi -
Recently at Linaro we've started a new tree
linaro-androidization-tracking, which is pretty much "common-3.1"[1] at
the moment on 3.1-rc8 basis.
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
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.
-Andy
[1] TI have a tree on omapzoom where we got the patches from
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-3.1
(Apologies for any duplication, googlegroups needs mail sent from Google mail)