On 22/05/12 04:02, Somebody in the thread at some point said:
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.
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
--
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
