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 automatically.
- 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