On Fri, 2016-09-02 at 08:04 -0700, James Bottomley wrote:
> On Fri, 2016-09-02 at 10:55 -0400, Rik van Riel wrote:
> > 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?
> 
> It costs a lot less to learn from history instead of repeating it. 
>  But, I suppose, it's not my money being wasted.

The fact that there is demand for a collaborative
project on a common kernel tree to carry features
for the embedded folks suggests they are already
feeling the pain themselves.

What is missing is the realization that we already
have such a tree, where everybody (not just the
embedded folks) are collaborating on features.

The upstream kernel.

The embedded companies have the choice between
paying to duplicate a lot of the upstream kernel
work themselves, or participating in a larger
community, with less duplication of effort, and
more work done by developers who are not on their
payrolls.

-- 

All Rights Reversed.