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%3Ba=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%3Ba=shortlog%3Bh=refs/heads/p-and...
(Apologies for any duplication, googlegroups needs mail sent from Google mail)