Preliminary 12.04 linux-linaro kernel tree
asac at linaro.org
Thu Apr 19 15:33:21 UTC 2012
On Thu, Apr 19, 2012 at 4:21 PM, Andrey Konovalov <
andrey.konovalov at linaro.org> wrote:
> On 04/19/2012 03:07 PM, Alexander Sack wrote:
>> On Thu, Apr 19, 2012 at 5:27 AM, Andy Green <andy.green at linaro.org
>> <mailto: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
>> > before. The major change here is that we're accepting a broader
>> > of topics, but in the end it'll also depend a lot on what is
>> > being worked on by each LT and WG.
>> >> I think you find it will have been better to stick with generating
>> >> 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
>> 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:
> 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?
> 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).
> 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
Without thinking I would say that every branch (tracking, stable, etc.) and
tag (release candidate, release etc.) should have the same -core subset
> 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?
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