On 22/05/12 04:02, Somebody in the thread at some point said:
On Thu, May 10, 2012 at 10:43 PM, Andy Greenandy.green@linaro.org wrote:
On 11/05/12 08:27, Somebody in the thread at some point said:
- in between RCs, we only move mainline on our linux-linaro release
baseline forward if we see a working tracking build that wouldn't drop any topics that already made it into this RC cycle.
The probability of getting a good unified tree follows the kernel cycle, we all have good reasons to have tried to arrive at a good, working, release. Sometimes we only get a reasonably good result a week or two after Linus' release.
For that reason maybe you should just be trying to 'release' a release-basis unified tree, ie, the 3.4 one targeted now as the deliverable. It still has meaning to make a monthly release of that since it can collect stable mainline updates and updates from each LT release tree that happened in the meanwhile.
We do need to create these intermediate unified trees so we know what to fix on our trees so they can go in smoothly, but it matters less then if one day half the LT trees are missing on it since it's of interest only for LTs and platform guys to study what else needs solving on the LT trees.
I still think you won't get anywhere useful until we are trying to build the unified trees for real. Then we can start the needed work to make them fit together properly, until then we're treading water in "technical debt". Discussing how to run the tree is something to do later after gaining this experience.
I had a look at the LT gits
ARM Merge-managed integration-linux-vexpress 3.4-rc4 TI Rebase-managed tilt-tracking 3.4-rc4 Freescale Merge-managed lt-3.4 3.4-rc3 Samsung Rebase-managed tracking 3.4-rc3 STE Merge-managed integration-linux-ux500 3.4-rc6
(wow STE - on igloocommunity.org - have a LOT of patches! I thought we were leading the way)
Actually locally TILT are on -rc6 but there was almost no conflict coming between -rc4 and -rc6. If you take the approach to merge these trees, I found that late in the cycle it's usually pretty forgiving about some variation in basis.
So why not give these all a test merge today and see what starts falling out? I am sure we all have something to fix and there may be larger issues like two trees with conflicting versions of, I dunno, Mali driver, that needs planning to resolve. Or if people aren't using linux-linaro-core-tracking to get their CMA and so on, we need to know and start that migration.
So, if I understood correctly, the llct would be the branch used to actually start producing a valuable path to get the unified tree in place.
Exactly.
As you said, it seems we should start trying to experiment merging everything together and deciding what can actually be moved or not to the core-tracking branch. This way we'd probably move to the direction of having one real unified tree, instead of just maintaining linux-linaro over the time.
Right.
So these are the useful branches I believe we'd end up having:
- Linux Linaro Core Tracking: main tree used to develop the common
changes across the different LTs/WGs and board flavours
Yes. This is already doing good stuff for us, we can carefully add more things here to give everyone an easy ride and eliminate desynchronized duplication between the trees.
- Linux Linaro: tree with llct that is stabilised between rc releases,
that's part of the LEB releases. This tree would also have additional topics from the LTs and WGs, in case they want to release it all into one single tree (releasing together with Linux Linaro is useful in a way we'll share QA and also helping identifying what other improvements might be needed in case of conflicts)
- Linux Linaro Tracking/Unified: a tree that could contain llct + all
the sauce maintained by all the LTs, to be used just for testing to help understanding what should be shared between LTs and be moved to core-tracking. This would help us getting to a position where we could identify early what are the conflicts, and work on getting a common solution with core-tracking before actually starting to send upstream.
Would this fit your needs?
I think you can forget the last two and just take care about llct. For a while I imagined there was just something I wasn't getting about this new llt scheme but now I believe it's simply unworkable and not thought through.
If you imagine just a little bit ahead of where we are today, with all LT on same or similar llct basis on any particular day, actually Andrey can imagine to wake up one morning and casually try to merge two or more LT trees and see what happens. They're on same basis, we moved most or eventually all duplicated content to a canonical version coming from llct... most of the thorns are removed from the path.
He will find:
1) merge conflicts... two or more trees both changed same code. "False alarms" will occur here a lot in Makefile and Kconfig, since other trees added stuff too, but there is no problem or bug. But there will be some genuine ones like we now know in Mali multiple trees screwed with same stuff. These will need discussion and examination of each others' changes and figure a good way to encapsulate, however general approach should be migrate the common changes (Mali basis at least) to llct and minimize diverged patches in LT trees.
2) configure conflicts... LT trees made bad assumptions about SoC assets not being dependent on SoC Arch config, and default to "y". So for example TI PM feature might insist to be enabled when building out the tree for Samsung ARCH device. It's a bug in that fictitious example in TI tree we can fix easily if we hear about it.
3) build conflicts... some trees accidentally added stuff based on <plat/blah.h> they have in their arch, but not in other trees leading to defines that aren't defined... again it's a bug in the trees that changed it, just needs discussion and explanation for simple fixes
4) breakage... workarounds and changes to common code like mmc core might be necessary or work on one arch but trash operation on another. Needs discussion on why there are changes to common core code in LT tree. Maybe the changes are really good news, in which case stick them in llct until they appear upstream. If they're dubious either convince LT to find a better way or eliminate them, or if not possible use flags for dynamic enable of the changes.
For problems 1-3, Andrey should drive it and stimulate discussion with LTs on lists about what a beneficial resolution looks like and get people to improve their trees so he can go again.
At 4, actually I think LTs involved will have to try to build Andrey's casually unified tree with their config alone initially and check for results same as the same LT tree Andrey used. It won't scale if we ask Andrey to also test all the LT trees. So long as LTs are not prodded to do it too often, it should be fine. Then in turn LTs need to create discussion about findings, like "it boots, but now in unified tree MMC OOPSes after a few seconds like this...", look at what other LT content affected that area etc.
If all the LTs involved agree they can recover their original tree's functionality from the unified one when using just their CONFIG, then it's ready to try to build out with a single kernel binary multiarch config and deal with the new load of problems from that, eventually when they're cleared a new round of LT testing with single kernel binary.
This was the approach we took to get OMAP4 + 5 single kernel binary in our current tree and it worked well. After we got it working we threw out the individual arch configs and now only build the single kernel binary one so there can be no slippage.
After we get some good result from the casually merged trees, to the extent we can build out all the same LT kernels that went in, we can think through what we learned and talk meaningfully about predictions and how to manage release of the tree.
-Andy