On Thu, Apr 19, 2012 at 4:21 PM, Andrey Konovalov < andrey.konova...@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.gr...@linaro.org >> <mailto:andy.gr...@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: > > 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 > anyway. 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? -- Alexander Sack 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
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
