On 09/04/12 12:13, the mail apparently from Ricardo Salveti included:
Hi -
1) Can we have linux stable point release content in tilt-3.4? Rather than
my doing it, isn't it better to add it to llc-3.4 and merge it on the lt
history tree periodically? That way every lt can get them from one place.
I don't see why merging the stable release contents would be an issue.
We could keep updating the tree based on stable-only releases, as long
as we still have at least one Landing Team interested on consuming it.
This would be another job that would probably be automated by Andrey's scripts.
Right it should usually be simple, although don't forget there is quite
a lot of avant garde content in llct, such as Androidization. Just
today I saw Xavier at TI find that merging of stable had a patch
conflicting with llct Androidization content.
2) What's the deal with things that were the latest and greatest at that
time, ie, the best "CMA" or whatever series was in tracking, but after it
got copied out to be linux-linaro-core-3.4, horrible bugs were fixed in
linux-linaro-tracking? What's happening is that TI are sticking with these
releases for a fair time as the basis for their release to customers.
The problem is that the main goal of pushing new content and branches
at the linux-linaro-tracking is mainly to help people getting their
own stuff at upstream (by providing an unified tree which can then be
used for QA and such). So, from the maintainer perspective, he'll
always be moving his own stuff based on the latest upstream available,
and that's why they are always integrated at the latest
linux-linaro-tracking as well (mostly following upstream).
Understood, and in itself that's obviously a good way.
If we decide to keep updating the older tree, that would probably need
a substantial and not necessarily trivial work on backporting the new
features and updates. Guess at least bugfixes would be ok, but I don't
think would be trivial to identify just the fixes at the latest
series.
I don't think we need to "keep updating" the older tree, in any
continuous sense like the tracking one.
What's causing concern is specific cases where big problems that went
out with the old tree were found and fixed in subsequent tracking work.
What happens now is the big problem stays landmine-style in the older
tree until real customers trip over it and waste a lot of time
characterizing it or trying to fix / resolve it. In fact it's already
understood and fixed elsewhere.
What would preferably happen is that when the "domain experts" for a
particular series in llct realize that the thing being fixed in tracking
means there's something horrible in the stable release, they at least
consider a minimal fix patch on the old tree, or ring a big bell on the
lists saying, "don't use XYZ on 3.4, we just found it's unreliable and
can crash with ABC. You need the implementation from 3.6 at least since
there's no workaround". Then we can discuss which lucky person should
look at backport, or if all the consumers who care about XYZ can migrate
to 3.6.
At the moment none of that is happening which increases uncertainty
about llct as a basis for medium-term release trees.
We don't need an SLA about it just the understanding that if a feature
goes in llct, the guys writing it need to keep a little bit of love in
their heart for also fixing the bigger problems later found in the code
even in its old age.
I can see there's tension between tracking-style fix it for the future, and
backport to old and crusty things, there's also issue of testing, but there
must be some cases where this makes some sense. Again people looking after
the feature tree for llct are best placed to make those calls about, "hm,
that looks like it should maybe also go on the last couple of llc release
trees".
What do you think about this?
I believe we can go on case by case, if we have people requesting us
to backport new features or branches over previous releases. If you
have any this point (or at least from TI), we can look and see what
would be needed to update at the 3.4 based trees, but would also be
nice if we can also get them involved on testing, so we know things
are working properly.
The problem is we are not in a position to know what to ask for until we
painfully stubbed our toes on it.
The "domain experts" who work on the topic content of llct are in a
position to know since they are knee-deep in it daily.
And since the content went in at llct level, it needs managing and
updating at llct level so all LTs get the benefit (and that point, LTs
will be on history trees, and can simply merge).
Do you have any idea about how long TI will keep this 3.4 based tree
maintained and supported? I saw you were about to move on working at
the 3.6 based tree, but don't know if that's just to keep things sane
(and near upstream), or because TI wants to have another well
supported tree.
Right we have started to kick tyres on 3.6 tracking but that has some
challenges that will take a while to fully overcome. tilt-3.4 has a lot
of power-related tuning that will need porting, there's a move to proper
DT, there will be an OMAP5 (not so much 4) focus, although we currently
hope to inherit a lot of working OMAP4 stuff from mainline automagically.
So the thinking is tilt-3.4 will be around for a while as the mature
OMAP4 solution with a lot of proven PM tuning and the 3.6 work is trying
to sort out OMAP5 support as its priority.
-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
