On Thu, May 10, 2012 at 10:43 PM, Andy Green <andy.gr...@linaro.org> wrote: > On 11/05/12 08:27, Somebody in the thread at some point said: > >> 4. 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. 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. 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 - 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? Thanks, -- Ricardo Salveti de Araujo _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
