On Fri, 2016-09-02 at 07:42 -0700, James Bottomley wrote:
> On Fri, 2016-09-02 at 10:54 +0100, Mark Brown wrote:
> > 
> > It's what people are doing for products, they want newer features
> > but
> > they also don't want to rebase their product kernel onto mainline
> > as
> > that's an even bigger integration risk.  People aren't using this 
> > kernel raw, they're using it as the basis for product
> > kernels.  What 
> > this is doing is getting a bunch of people using the same
> > backports 
> > which shares effort and hopefully makes it more likely that some
> > of 
> > the security relevant features will get deployed in products. 
> 
> 
> And history repeats itself: this is almost the precise rationale the
> distros used for all their out of tree patches in their 2.4
> enterprise
> kernels.  The disaster that ended up with (patch sets bigger than the
> kernel itself with no way of getting them all upstream) is what led
> directly to their upstream first policy.
> 
> The fact that all the distros track upstream more closely also means
> it's better tested: the farther away from upstream you move, the more
> problems you'll have.
> 
What exactly is the business case for re-learning the same
lesson the hard way, anyway?

The embedded people can either learn from the mistakes the
distro vendors made in the 2.4 era, which was repeated by
the Android kernel team later on, or they can choose to
repeat that mistake and learn things the hard way.

With 6-9 month time to market on products, do you really
have time for a 12 month rebase of a gigantic pile of
patches?

-- 

All Rights Reversed.