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