Preliminary 12.04 linux-linaro kernel tree
andy.green at linaro.org
Thu Apr 19 23:16:18 UTC 2012
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)
> 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
"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
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-dev