Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time

[Jiri Kosina <jikos@kernel.org>]

On Wed, 5 Sep 2018, Thomas Gleixner wrote:

> I totally agree that we want backports and stable kernels, but I really
> have to ask whether backporting all the way back to the begin of the
> universe makes any sense at all. I know that the enterprise folks still
> believe that their frankenkernels are valuable and make sense, but given
> the shit they rolled out this year, there is enough factual evidence that
> this model is broken beyond repair.

I don't think any enterprise distro vendor is asking for stable LTS for 
super-historical kernels. Major RHEL is (afaik) 2.6.32 and 3.10-based, 
major SLE is 3.0, 4.4 and 4.12 based.

So there is one intersection there, and that's 4.4.

Supporting such old monsters is a business decision that was made by said 
vendors, so it's perfectly fine they (actually "we" :) ) are suffering on 
their (our) own.

If enterprise vendors would be able to create a working business 
relationship with partners and customers around 'rolling' kernel versions 
in enterprise distributions one day, that'd of course be awesome.

We're not there yet, but things are definitely changing on this front as 
well. For example we (as in "SUSE") are now more pro-active updating 
kernel version between enterprise distro service packs than we've 
historically been. It can be seen as one of the steps towards more 
'rolling' flexibility, but it's sometimes a rather hard sell to the 
enterprise.

> IOW, in the light of meltdown/spectre all effort should have been put 
> into getting 4.14 and 4.9 fixed instead of diverting our very limited 
> capcity to create monstrosities back to 2.6 variants.

I agree that it'd be an ideal world, but it's guaranteed that if we just 
say to the people running some of our 2.6 kernel under a very special 
contract that they have to all of a sudden move to 4.14, we'll just 
immediately lose that contract (and someone else will immediately plug the 
hole on the market and create perhaps even worse backport for them), and 
for various reasons we don't want that to happen :)

Such contracts are usually set up in a way that only very specific fixes 
can be requested for said kernels. We've historically put our bets on the 
fact that we'll be able to provide those rare fixes even for 2.6, and it 
worked well.
Now we're paying back a bit of course (because spectre/meltdown of course 
qualifies), but upstream can completely and happily ignore that.

Thanks,

-- 
Jiri Kosina
SUSE Labs