Re: [Ksummit-discuss] [Stable kernel] feature backporting collaboration

["gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>]

On Fri, Sep 02, 2016 at 03:31:03PM -0400, Levin, Alexander wrote:
> Hi Ted,
> 
> On Fri, Sep 02, 2016 at 09:47:11AM -0400, Theodore Ts'o wrote:
> > Or for that matter, why not simply going to the latest mainline
> > kernel.  Since the SOC vendors aren't taking updates from the LTS
> > kernel anyway, if the LTS kernel exists only as a patch repository
> > where people can look for security fixes and bug fixes (sometimes
> > after the upstream maintainer has to point out it's in the LTS
> > kernel), if they take, say, 4.7, in the future they might need to take
> > a look at 4.8.x, 4.9.x, etc., until the next LTS kernel is declared.
> > So that means that an SOC vendor or a downstream product vendors might
> > have to look at 3 or 4 patch releases instead of one.  Is that really
> > that hard?
> 
> I agree with everything you said besides this last paragraph, and it's
> our fault.
> 
> In theory, the flow of commits that need to go into the stable tree should
> have uniform distribution: Linus takes fixes at any point in time, so unlike
> new features that come in only during the merge window fixes should be
> constantly flowing in.
> 
> However, this is not the case; looking at LTS kernel releases during merge
> windows we can see that the volume of commits that go into LTS kernel is much
> higher than during release candidate cycles. Why? people still hold off on
> sending fixes for a variety of reasons, which isn't the way it's supposed to
> happen.

I disagree.  I tag things for stable and then hold off to send them in
until -rc1 because of a variety of good reasons:
	- it needs more testing
	- it really isn't that big of a deal, and can wait a few weeks

Only the "really big" things usually get sent from me to Linus after
-rc1 is out, stuff that affects a number of people (and not just one odd
device/platform), or fixes a regression.

I imagine other maintainers do the same thing, so I wouldn't read all
that much into this.

> As a result, I'd never want to use mainline for production. The first kernel
> I'd consider is a stable kernel that has taken in everything that was sent
> during a merge window of the next release.

That usually feels like the most "unstable" stable release for some
reason, maybe because of the size, I don't have any real numbers to back
it up, as they all are obviously "good and stable" releases :)

thanks,

greg k-h