Announce: TILT tracking Androidization trees

[Andy Green]

On 10/04/2011 10:36 PM, Somebody in the thread at some point said:

Hi -

>     The second branch is "tilt-android-tracking".  This is our main
>     tracking branch tilt-tracking for Panda enablement we have been
>     running for some months combined with
>     "linaro-androidization-__tracking" above.
>
>
> Sounds like an interesting approach to me. Will you try keep this
> running as a pilot for one linus head cycle? I think that would give us
> good initial data to decide how to do all this officially across the
> organization in future.

Yes that's my plan.  It should be at its worst after 3.1 release in 
terms of conflicts needing fixing for tracking, then at its worst around 
3.2-rc7 or whatever when next common shows up in terms of refreshing 
against its 'upstream' so to speak.  My experience with the TILT 
patchset and tracking suggests we can probably cope, but well we have to 
see what happens during that cycle.

> One thing that isn't entirely clear from what you describe is whether we
> would do the forward porting for new linus HEAD versions on our own or
> if we would wait until we get a first androidization from either google
> or our members?

You're right it's a good question.  What I have in mind is not to leave 
the patchset as the current pile of semi-history patches all 
intermingled but impose topic-branch ordering on them.

So for example, I was quite surprised to see so many patches on net core 
subsystem, lots on net / wireless subsystem too all through the series. 
  It would be interesting to re-order the patches so we had all the net 
core stuff in one layer, wireless-related stuff in another layer all 
together and so on, same way tilt-tracking is composed.  We don't have 
to get OCD about it and do everything, we can have a topic at the end 
with stuff contaminated from all directions and leave it like it is for 
now.  But I guess most patches will go into a topic if it is ordered 
correctly.

I had a quick go at this over the weekend just to see where it led, what 
I found is that many patches even in net core subsystem have 
dependencies on Android features like PARANOID_NETWORK (eg, #ifdef 
...PANANOID_NETWORK in there).  It looked like it could go that if the 
first topic was introducing these kind of major fundamental Android 
features, the other subsystem topics might go on relatively cleanly.

So if we imagine that has been done, the issue as you point out is how 
to refresh the radically changed series against the next common-x.x when 
it appears.  Well, the fact we chopped it about in topics is probably 
not so critical as the changes coming between old and new common- itself 
in terms of removed, modified and additional patches.

Ideally, we are able to cooperate with the guys in Google who run 
common-.  They actually face the same uplevel issues as this tree will, 
if we were able to make the tracking branch common-tracking at Google 
then there wouldn't be any issue there.  But that sounds like a bit of a 
happy dream at the moment since I don't even know who runs it today. 
But I bet he would be quite interested in this subject.

If we continue to exist in the current grimy reality instead, being 
consumers of common- that keep it warm over the whole cycle, what I plan 
is to get linaro-androidization-tracking was on the same base as this 
first new common-, and 'rebase' new and changed patches into our topic 
structure until there is zero diff between our tree and the new common-, 
despite the patchsets are managed completely differently.  We can have 
confidence the result is the same when we see no diff between the trees. 
  After that, the patchset will diverge from common- because the basis 
is tracking and because we have to modify the patchset to match the 
changing basis, but that's the idea so that's OK.  We can bring in 
patches added on common- later into the topics as well ongoing.

If the next common- is so radically different that plan blows up, well, 
the worst that can happen is we have to just take the next common- 
patchset exactly as it is when the two trees have the same basis and 
then diverge with tracking as before.  That's not really so bad, we can 
keep our 'promise' to consumers of our tree even if we lost or had to 
redo the topic structure in that event.  However I guess there's 
normally few changes between say bunch of net core subsystem patches 
from last time and next common- and we stand a good chance to keep the 
topic structure going from last common-.

Today even android.git.kernel.org is not there so we have to sort out a 
way to follow common-3.1 at all as well, but that's everyone's problem 
so I assume that will get solved shortly.  We're this far along thanks 
to TI doing their androidization tree publicly.

>     Lastly TILT is also providing tracking versions of the Android
>     autobuilt Panda-LEB tarballs that are ready to use.  These are the
>     Autobuilt tarballs with the kernel replaced with a tracking one by
>     us.  You can find them linked from our git repo in
>     tilt-android-tracking column of the status table there.
>
>
> Mid term I would very much like to see those builds coming out of the
> android build system, going through LAVA, with results as part of our
> kernel CI in the dashboard and so on...
>
> What is holding you back from using the build service atm?

Nothing on our side, in fact I have requested it.

It just needs somebody to cut-and-paste the "panda-LEB" XML and change 
the kernel branch name to 'tilt-android-tracking'.  There was no ETA for 
it so I have rolled our own because I can't get official ones as it 
stands.  Ongoing official Linaro ones will be very welcome.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog