andy.green at linaro.org
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
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
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
More information about the linaro-kernel