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.
> From the maintainer pov it's hard to decide what to do in such cases.
> Currently we're working on a first-come, first-served model, and
> getting the list of branches/topics per WG and LT. Once we start
> having major conflicts, it'll be up to the maintainer to either drop
> both branches/topics, or select the one that looks more promising from
> the upstreaming pov.
This topic dropping thing is not gonna be very useful, on our tree
anyway. Most things depend on something else, like DSS -> HDMI -> (HDMI
audio / HDMI audio 5.1), DSS + CMA -> omapdrm. Unless it's an endpoint,
it won't come out.
If stuff wants ejecting because it patches mmc core and now will infect
other LT trees with that, well, if it's mmc boot, just pull the whole
tree, presumably they need those patches to boot.
All the time this gets talked about but nobody has actually merged all
the trees, is wasted time (four months + now)
> Without having a strong maintainer, that would work with the topic
> maintainers to find the best way to solve the conflicts, I don't think
> there's an easy way to get this going.
The way forward is to align the LTs using the linux-linaro flavouring
tree to provide mandatory versions of patch series used by more than one
LT kernel.
It's that which is stopping casual merging of multiple LT trees.
>> Putting one LT tree in there (arm lt content is orthogonal to full tree)
>> is the degenerate case that won't expose these issues.
>
> But then how would you deal with the current topics list? How to
> identify which topics/branches we want to integrate at the common
> baseline? Would be enough if we publish the tools to do the
> branch/topics permutation for you to be able to validate your own
> work?
This topic exclusion thing is a red herring.
- align the patch series used by multiple trees by providing central,
definitive version in linux-linaro flavouring tree
- get the LTs - if it's practical for them, sometimes it can actually
be impossible, it which case accept they're sitting this one out - to
align on the mandatory version
- just combine the trees already! What I did is make the LT trees
single fat topics each in the combined tree, used my existing tools to
do serialized rebase. It took a lot of real time to bind them since it
thousands and thousands of patches.
- If stuff's busted, post on lists and tell LT about what's needed to
do, eg
- Your tree with Mali driver in doesn't build with Mali
deconfigured, could you sort that out?
- diffstat says your tree craps all over ./kernel... or ./drivers or
core mmc code - what's that about?
- your tree says that driver for your SoC asset is default y, but it
does not depend on your SoC configured in, can you fix that?
>>> On the general point of conflicts through putting multiple hw enablement
>>> together: We have discussed a feature of "conflicting" topics that would
>>> mitigate the problem by producing a tree for each topic that has
>>> conflicts that leaves out the conflicting topics. At this point in time,
>>> we cannot handle conflicting topics yet ... our tools have to get in
>>> shape for that first and we expect to be closer to such a point by Connect.
>>>
>>> Last: ultimately we hope that putting things together will ensure that
>>> we figure out how to stay aligned and non conflicting. I think it's an
>>> important exercise to go through and learn from.
>>
>> Sticking one LT tree in there is not putting anything together.
>>
>> Back in Dec I put 4 LT trees together and got interesting results (trees
>> with mali in did not test it deconfigured, various other small issues
>> about config defaults not making sense if SoC ARCH not also enabled,
>> some LTs had mmc core code patches) but they were ignored. This effort
>> at HEAD is great but you can enable the LTs to get ahead of the problems
>> that are coming by doing what I did in Dec, a test combine of all LT
>> trees at v3.3. Then we can say we are actually "putting things together".
>
> I don't see why we can't have both, and why enabling one LT would put
> the others in risk, if we're able to work together deciding what makes
> sense to be applied and what should be removed/re-worked.
Take the case every other LT is in there... our last 3.3 build is 2100
patches ahead of v3.3. I guess we're at a world record right now but
still, with 4 LTs in there why am I rebasing all this junk all the time
when I just want to get my kernel working with the mandatory components.
Just give me a little tree with the mandatory components. When it's
working, we can combine them from the starting point that the kernel
worked with the same flavouring before unification, so any problems are
coming from the other trees / unification action.
Don't forget just because other LT tree is in this combined tree does
not mean it's saintly, it just means nothing combined with it yet that
blew chunks because it conflicted with that tree's badness.
We need to separate out the process of aligning with mandatory series on
our tree alone, and the process of interoperation with other trees.
> The current tree is still useful in many ways, and it also helps
> showing and getting the conflicts at the same time we have people
> working directly on them. With one strong maintainer, and enough
> discussions with the topic owners, I don't see that this tree will be
> useless to the point of being just a dump of what Linaro is currently
> working on.
>
> Get your list of topics, and check how it goes with the current tree.
> Test it yourself first, and then propose the branches/topics that you
> think it'd be useful to be integrated at the common baseline. That
> will help fixing the issues before going upstream, and getting the
> same enablement fixes across LT/WGs.
>
> You need to remember that this tree will be used and tested by mostly
> everyone working on kernel development inside Linaro. This will also
> be part of the LEBs and tested/verified by the QA team later on.
I hope this lengthy reply has helped us converge.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
