On Thu, Apr 19, 2012 at 5:27 AM, Andy Green
<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.
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? At best we could sneak that service in for todays release candidate?
Happy to talk offline if there are questions/doubts etc.