Andy Green at
Wed Nov 23 23:28:39 UTC 2011

On 11/24/2011 03:18 AM, Somebody in the thread at some point said:

>> As I mentioned in the talk I gave at Connect about lt-tools, the fact that
>> we're both tracking near Linus HEAD allows us to casually combine the trees
>> for the first time if we can arrange for our basis to be relatively close.

> Great work guys! FYI, we've had someone join the KWG who will be driving the
> kernel process work and taking over the maintainer role and I'll have him sync
> up with you.

Assuming you're just talking about linaro-unified-tracking, what 
maintaining that will look like is an interesting topic that we have 
never discussed.  And it does need discussing before assuming "someone" 
from KWG can just walk into doing it.  I'm happy to get and give some 
help but then we need to make sure whoever 'takes over' is doing the 
same or better than I would have done.

Ideally it would be trivial because you would only accept "zero damage" 
trees from the LTs, ie trees that don't patch anything outside their 
arch, add common drivers, or add arch-specific shims on common drivers 
like musb case.

John Stultz pointed out in a discussion at Connect that availability of 
contributor trees from the LTs might be episodic due to damage from 
changing upstream basis making them unavailable.  That's certainly 
correct and it means that only a subset of trees (maybe zero) are 
workable on any given Linus HEAD.  Specifically there's a reason the 
"last known good" tree from a LT will often not rebase in a clean or 
workable way on newer Linus HEAD basis: the same upstream changes that 
broke it for the lt guys.

However I know from experience that all the serious arch damage comes 
from upstream in the earlier -rcs.  In the latter half of the cycle, 
there's less arch patching coming from upstream and what there is, is 
less disruptive.

So maintaining this tree will not look like how you may casually expect 
in a number of ways:

  - the contributor trees are all rebase trees with no history, keeping 
a history tree for linaro-unified-tracking makes no sense.  You'll need 
a tagging or other archival scheme to simulate a history.

  - coordination with lt tracking maintainers to agree an approximate 
rendezvous basis for next unified composition will be constantly 
necessary.  It'll maybe be possible to use the -rcs for this but it's 
not necessary and might not even be a good idea if it discourages lt 
rebases inbetween -rcs.  (Actually, there's some flex in that since if 
no patches affecting the lt tree changes appeared upstream since its 
last basis, you can uplevel it cleanly.  But the more lt trees involved 
in unification the less chance that no patch involving their arch came 
and the stricter the need for a rendezvous basis.)

  - which lt trees can appear on a given build of the unified tree 
depends if they can arrange to provide a tree based on the "rendezvous 
point" that time.  So support for lt trees in a given build will vary, 
sometimes pre-rc2 say it won't be possible to build the unified tree at 
all because everyone has had their tree trashed by changes upstream. 
Other times one or a few will be available.

  - one major goal of doing the tracking trees at all in the lts is to 
have the best possible release version available as soon as it is 
released.  So there is a lot of focus on solving as many uplevel issues 
as possible by the end of the cycle.

  - over the kernel cycle then, it will tend that more lt trees are able 
to rendezvous and take part in these unified compositions with the goal 
they're all there for some time before release.

  - at release time, the tree can be cloned into a separate release 
branch that is maintained strictly as a history tree, like 
linaro-unified-3.2.  For a little while backport between lt tracking 
trees and the release tree will be easy but generally it's better to 
just fix it on tracking and leave the release be unless it's something 
critical.  The next release will inherit the fix from tracking 

  - the unified tree will need build-testing for every lt defconfig 
before public push.  LAVA testing will be great but it's most critical 
it at least builds for everything.


Andy Green | TI Landing Team Leader │ Open source software for ARM SoCs | Follow Linaro  -!/linaroorg -

More information about the linaro-dev mailing list