Good afternoon Andy, I am currently working on rebasing the STE GLK kernel to the androidization branch. Doing so I have the following questions:
1. You have made it clear that linaro-androidization-tracking is tracking Linus HEAD but is it also tracking kernel/common.git HEAD on the android side ? 2. What will be the rebase strategy ? Every week ? And when you do rebase, how do you intend to let the followers (like me) know ? Best regards, Mathieu. On 11-10-05 09: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. > > -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 > > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
