Preliminary 12.04 linux-linaro kernel tree
asac at linaro.org
Thu Apr 19 11:07:29 UTC 2012
On Thu, Apr 19, 2012 at 5:27 AM, Andy Green <andy.green at 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.
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linaro-dev