On 04/19/2012 03:07 PM, Alexander Sack wrote:
<mailto:andy.green@linaro.org>> wrote:
On 04/19/2012 08:53 AM, Somebody in the thread at some point said:
>> OK, so this is a major change to what linux-linaro was before.
>
> While this is different, it's not entirely different from what we had
> before. The major change here is that we're accepting a broader range
> of topics, but in the end it'll also depend a lot on what is
currently
> being worked on by each LT and WG.
>
>> I think you find it will have been better to stick with generating a
>> separate flavouring tree without unification content, because
you have
>> created a chicken-and-egg situation now.
>
> I think that will depend a lot of the topic list and the respective
> content. While some topics are easy to identify as enablement, and
> with good possibilities to have conflicts or broken/bad solution,
> there's no simple way to classify topic types/groups.
>
> In the past we also wanted to publish most branches we could at
> linux-linaro, even from all the LTs, but unfortunately that didn't
> happen as expected and we ended up just with core changes.
I'm not sure I made the problem clear enough.
If you guys decide to include CMA series try #999 in your combined tree,
the LTs have to make sure their kernels work with CMA #999 before you
can combine them.
Because if LT#1 has CMA #1234 and LT#2 has CMA #4567, you can't combine
them, they'll conflict all over with mutually exclusive resolutions.
There's no way to solve the conflict that satisfies both kernels (and
any on the CMA #999 you actually want).
Bearing that in mind, the LTs need access to a flavouring tree with CMA
#999 in it (along with any other mandatory series) beforehand so they
can work on aligning and testing their kernel to your mandated version,
so they will all offer kernels with CMA#999, and you can combine them
and get them all coming on CMA #999.
> This kind of conflicts will for sure happen once we start merging
> topics from different LTs. I believe we just need to make a clear
> statement on how we're planning to deal with conflicts, and how the
> LTs can use the current linux-linaro as based when checking for such
> conflicts, problems.
It's not hard to solve - just publish the flavouring tree, it anyway
exists as part of Andrey's flow.
That's why I've changed the topics merge order last night:
On 04/19/2012 12:22 AM, Andrey Konovalov wrote:
> Changes to the previous version:
> * topics merge order changed: generic topics first, LT's topics last:
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 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).I talked to Andy and I agree that pushing the state of our linux-linaro
tree _after_ the WG topics were merged but _before_ all the LT topics go
in as a "mandatory" branch would offer a nice option to consume just our
core subset of changes. So far I thought the topics alone would be good
enough, but I understand the value of having a one shot core tree for
some of the participants in the linux-linaro effort.
Also, I agree that we already have that state while merging topics
anyway, so making that available should be really cheap - especially if
we are OK that that "mandatory" branch (linux-linaro-tracking-core) will
not be validated and released independently, but only be made available
to make consuming our linaro core kernel work easier.
Andy and me seem to be aligned on that point and there was agreement
that validating just the core set without enablement wouldn't be expected.
Ultimately I like the idea of establishing all or a subset of WG topics
as the "linaro mandatory" set that the LTs have to converge around...
this includes making decisions on what CMA version everybody should use.
With that I would say: let's do it.
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?
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.
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.
At best we could sneak that service in for todays
release candidate?
That's why we could consider the "linux-linaro-tracking*" branches to follow the mainline tip more closely than with per -rc "granularity".