On 20 June 2013 17:22, Mark Brown broonie@linaro.org wrote:
On Thu, Jun 20, 2013 at 08:02:54PM +0800, Andy Green wrote:
On 20 June 2013 19:16, Mark Brown broonie@sirena.org.uk wrote:
Please don't top post on upstream style lists such as this one.
shrug
It's important to follow good practice here; it helps set a good example for people of upstream processes.
This is happening anyway and will continue to happen for the forseeable future in the consumer electronics space, it's just a function of shipping product on something other than -next really. I'd actually hope that our strong policy on using upstream code and backporting it might help a little here, keeping things more in sync. It's not a particular problem to work on a backport for a product so long as the backport and upstream are reasonably in sync.
Linaro works with its members to maintain kernels for them via Landing Teams. Linaro has always had a "strong policy on upstream code" but that is the art of the possible when you work directly with member companies who variously may not want things upstreamed because somebody might learn something about their IP, have a large number of engineers already supposedly upstreaming things or not even understand why upstreaming things is worth the time.
I'm sure you have a good handle on nice clean, sane upstream world but I'm telling you something specific about Linaro and LT experience with members.
So, my previous job was all about shipping into smartphones so I'm more than familiar with the situation here - this is in no way specific to Linaro, it's a pressure felt by everyone shipping into the consumer electronics space. To me part of teaching people about the value of upstreaming is teaching them how that process interacts with and helps the process of stabalisation for release.
I don't think the people you're worrying about here have any intention of running a LTS kernel directly, the broad plan is that they will take the LTS and use it as a basis in the same way they currently do with upstream.
You clearly do not know the people I am worrying about.
I'm pretty sure I've actually been one of them, at least from the point of view of a commercial pressure/delivery point of view.
The investment in old kernels thing that you mention is not really an issue these days thanks to Android, it's got people used to an upgrade cycle. The reason people standardise on v3.4 right now is more things like being more comfortable using whatever Google were using for their lead device and it giving all the component makers a target to aim at so the product people don't have integration hassle.
What that causes is a large number of engineers spending time on "disposable kernels" that are not aligned with, and don't feed upstream. We saw it at TI before many of the "large number of
Sure, it's not ideal and one of the things you guys on the landing teams need to be teaching people is how to do this effectively. The issue here isn't that people are picking a kernel and stabalising for release on that, it's that they're frequently doing so in an ineffective fashion. What you're talking about here isn't sticking to a single kernel and staying with it for ever more, it's something different to that. More on this below...
engineers" wasting time on that got canned (it didn't stop them just slowed them down ^^). People are still working on 3.0 even and 3.4 now, sometimes without DT, when 3.10 will soon be here, it's actually
Essentially everyone in the Android space will be working on v3.4 up until the release of Key Lime Pie. That's the stable kernel for Jelly Bean, that's what everyone works with. For ICS it was v3.0, though that's pretty much dead at this point for anything except support.
As far as device tree goes... it's not really solving a problem that people doing phones have. People will use it (and IME do use it) when it's a standard feature in the baseline kernel but there's no real pull to backport it, if anything it's likely to cause problems with third party code as nobody else is using it on that kernel version so there's unlikely to be DT support in their drivers.
not a good situation and not in itself what Linaro is meant to encourage. To the extent an LTS kernel will encourage / enable / legitimize that when people could be on tracking kernels, it's a problem. In other cases LTS usage is legitimate especially if the platform is mature.
In the Landing Teams, it's Linaro's policy to encourage the members to make sure their stuff is tracking Linus' HEAD so they always have a contemporary kernel with all the pieces, reducing the barrier to upstreaming the content.
So what I think the landing teams need to be doing here is unchanged - you need to be showing people how to develop in such a way that the backport/release code and upstream code don't shift too far apart so work done in one can be readily applied to the other, and helping them make sure that things are kept in sync so this is tractable.
I don't see that fitting in with my LT's plans at all. LSK has not been accounted for at all, other than as a team requiring support on an ad-hoc basis, along with many other teams inside Linaro.
I would actually hope that in producing a stable kernel Linaro will provide a positive example of how this can be done effectively that people can look to when trying to understand what's going on. When we keep our stable trees trackable back to current upstream work we will be showing this process in action which the landing teams will be able to point to when making the case for this approach to their member companies.
The other thing that is often a good example here is going through the process of moving to a new kernel version when you've been tracking upstream - this often brings home the advantages to people. I've seen some companies in this space go from just not caring about upstream to strongly advocating for upstream after going through this process.
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel