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