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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
