On 04/19/2012 11:33 PM, Somebody in the thread at some point said:
Andrey/Ricardo: do you agree? Can we make such a "linux-linaro-tracking-core" branch (and a tag accordingly) available that basically reflects the state we have after merging WG topics and before LT topics? Sure :) With just one difference probably. Shouldn't this "linux-linaro-tracking-core" branch be mainline tip based, not just the most recent -rc? (So it would be the "real" tracking tree.) I
That's the spirit ^^ Actually we found (with tilt patchload anyway) at start of kernel cycle, there is often heavy breakage coming from mainline HEAD day by day or even hour by hour. Keeping on top of that so you don't experience it all at once is really important.
But usually after the middle of the cycle, even trees that differ by two -rcs are basically compatible and can be merged / rebased pretty painlessly.
However... spare a thought for how this'll scale for you personally when you are dealing with say 10 LT trees each with 1000 patches.
When our tree hit 2100 patches (it should be half that at 3.4) it was taking hours to rebase, merging is not markedly faster. It's single-threaded so throwing more cores at it doesn't help.
It's another reason separating out -core flavouring uplevel and unified uplevel is the right path.
also planned to have a "linux-linaro-tracking" branch to be exactly the same "linux-linaro-tracking-core" branch plus the current LT's topics for the next linux-linaro release. The "linux-linaro-tracking*" branches would be for new work being done (like moving to new CMA version), while the linux-linaro branch would be used mostly for testing and bug fixing. When we see that the "linux-linaro-tracking" is good enough, we move "linux-linaro" to it (rebasing to the nearest -rc if necessary). This implies that two versions of the topics must be supported: the "current" (use the same -rc as linux-linaro) and the "next" (mainline tip based) ones. Guess the WGs and the LTs are already doing something similar anyway.
In tilt anyway we just have tracking and release-based branch. We do use tags now to give tracking a granular history. But there's no concept of -rc based sub-release atm. I guess you mention -rc basis because you're looking to make it a "rendezvous point" for combined tree, which is fair enough, although later in the cycle I found it's really accepting of quite a bit of deviation from exact same basis.
Generally, we only trash tracking once per cycle at the start when mainline undergoes its convulsion. The rest of the cycle, tracking should normally be tending to get better monotonically, since I don't normally push a new tree until it seems to be performing as well as what's in the repo already, unless there are special circumstances.
Without thinking I would say that every branch (tracking, stable, etc.) and tag (release candidate, release etc.) should have the same -core subset explicitely marked.
At best we could sneak that service in for todays release candidate? We probably could. But this has very little value for the current 12.04 release. Having "linux-linaro-tracking-core" *well before* the 12.05 release is much more important than right before the 12.04. That's why we could consider the "linux-linaro-tracking*" branches to follow the mainline tip more closely than with per -rc "granularity".My understanding is that it would help for Andy for this release. Can we just do the tags/branches?
No I did not mention anything about that. Today we only have half a tree undergoing a delayed rebase on 3.4-rc3+. That's running on its own timetable (ie, as fast as we can do it) that is completely disconnected to any monthly release action.
We need this -core thing not to speed us up for a monthly deadline but because existing approach isn't workable.
We better get used to the idea that now we want HEAD of everything (laudably) none of these trees, the LT ones, mainline, the mandatory source trees, none of them intrinsically care a fig about some random monthly release deadline and will only be in sync with what you want by occasional accident.
"Last known good" approach is not what you might think in this case either, since to combine them you'll have to revert all the trees to the same (or similar if late in the cycle) basis point, and for some LTs having to also revert to match the bad boy, that may be in worse state than their HEAD.
You'll sometimes only be able reissue "last known good" combined tree, not generate a new one at all. The combined tree has some "unique characteristics".
-Andy