On 11/05/12 08:32, Somebody in the thread at some point said:
On Fri, May 11, 2012 at 2:20 AM, Andy Green<andy.gr...@linaro.org> wrote:
On 11/05/12 07:43, Somebody in the thread at some point said:
On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If
the current one performs best and is on a random HEAD commit, we
certainly shouldn't wind it backwards to last -rc that performs worse
just because that's "easier to communicate".
I agree, I wasn't envisioning winding backwards, more that we stop
winding forwards at a chosen -rc, or stop merging topics on a Friday,
bring the common tree up-to-date with the weekends Torvalds -rc, then
build, test and fix this ready for Linaro RC on the Friday.
Right... the problem with that would have been though that on a random day -
and Linaro's monthly release cycle is random for tracking - our tracking may
be dead. Right now I have local tracking tree that's considerably ahead of
last public push but OMAP4 boot dies in a novel and cool way we didn't get
to the bottom of yet.
We have good local-to-LT reasons for having got ourselves into that
situation, we took in 70 patches from TI that are fixes or improvements to
core support we want to have in for 3.4. That reasoning might occur the day
or week before this Linaro monthly release and we should again choose to
temporarily trash the tree. Sometimes, we get demand to hold tracking for
other reasons again asynchronous to monthly release.
In short monthly release action will have to make do with "last thing that
was working best" as a single LT tree and for unified "last unified build
that was working best for most trees", which sometimes might be weeks old.
To facilitate the single LT case we are tagging our pushes we believe are
worth something, even if they might go backwards sometimes as we integrate
new drops of stuff.
For ARM LT the situation is a bit simpler, you have largely parallel feature
trees with new - super valuable, don't get me wrong - content, in our case
we have 1,000 - 2,000 patches with conflicting content to definitive stuff
pouring in to mainline all the time. We usually can't do any special
planning to converge with the monthly release. (Nor will it get better in
medium term, 3.5 has a huge convulsion in hwmod coming that might send us
back to the Stone Age for a while)
From my (granted high level) perspective keeping good logs/statistics
of patches/topics that cause conflicts and pain over and over again
might serve as good indication to target investment in upstreaming or
frameworks improvements/refactoring.
I assume this idea has been played through? What's the plan forward to
solve this problem? Maybe if we look closely there might be potential
base framework topics hidden that could be tackled by our kernel WG to
help you out mid/long term?
We have been doing quite a bit of musing and discussion about how to
make this better, the main thing that would help is greater integration
to other pieces of TI that are the "domain experts" for our topics.
That has problems though, we are focused on tracking Linus HEAD to
produce featureful Linus release trees at very low latency. The member
domain experts are focused on upstream solution on linux-omap-next
basis, and at timescale mandated by upstream demands about how and with
what their solutions must work.
I wish we could get KWG to do "something" that would help but I think
the underlying issue is we are on a different basis than where all the
effort is being poured into these topics by TI. Then we only see the
result of that work when it comes back on our mainline basis after a
long lag.
If we just waited for everything, there'd be no point having an LT tree,
although my life would be easier ^^, it means we have to take or
scavenge and rebase more or less aging pieces that we are alone with for
uplevel. Surprisingly that has been fairly workable for us. For
example there's 650 patches near the start of our tree we uplevelled
from 3.1 basis back in Feb that provides the core OMAP4 and OMAP5
support. I don't find it hard to imagine a better flow but we are just
one piece of the puzzle and there are genuine disconnects such as
different goals leading to different basis-trees (and different belief
about suitability of merge-managed trees as input to rebase-managed
process).
In any event nobody can do anything about hwmod changes coming down the
pike we will just have to adapt to whatever it is (I found people don't
want to hear about how to get rid of hwmod altogether ^^).
We plan to discuss this in depth at the HK Connect with all the
stakeholders and see if we can find a better way to interface that
provides advantages to everyone.
-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
