On 24 June 2013 19:24, Mark Brown broonie@linaro.org wrote:
On Mon, Jun 24, 2013 at 09:08:23AM +0800, Andy Green wrote:
However this LKS kernel will definitely make tracking activity harder for us. The problem will be all the driver integration focus at the member will be at LKS kernel and not tracking. Since LKS has a direct line to product ship date, parallel driver integration at later tracking kernel they're not shipping will seem like a distraction. We could do the driver integration engineering work at tracking and backport to LKS, but this really is needlessly inefficient from product-focused observer POV.
So, as David said this won't cover everything Linaro does so hopefully people will want to track our development stuff to play with those toys.
Whatever way you look at it this complicates Linaro's story.
There's no upstream path for engineering done on top of the older, stable kernel. I don't mean the work Mark is doing I mean the "BSP" work done on top of LKS to make it useful in actual products.
It may still be a good idea to enter the business of supporting stable product kernels but it has knock-ons; it's much more like a one-off consultancy activity.
The other thing I'd point out here is that people are already shipping products based on stable kernels today; the issues you mention are there already and ignoring them doesn't make them go away. If anything us providing some of the backport will hopefully avoid people needing to spend time doing that for themselves which ought to be helpful.
Yes. But the tree you're making will realistically be a starting point for a bunch of product kernels. In the case of LTs they'll be doing that product driver integration work which previously we did at HEAD on an older kernel. It's not the end of the world but it's philosophically and practically a bit different.
We might at the same time need to think about the general Linaro approach to burning energy on trees that are not going to leave a useful legacy to make sure the result is a bit more balanced.
-Andy