On 10/05/2011 08:37 AM, Andy Green wrote: > 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.
I've been working on a set of broken-out Android patches, in quilt format, with exactly the same goal. It's much easier (at least for me) to maintain the differences as distinct patches using quilt, rather than as a series (or set of branches) of git commits. But possibly I'm just missing how to do this easily with git. I would very much like to compare approaches, and possibly share the workload of maintaining such a thing. -- Tim ============================= Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment ============================= -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
