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

["Levin, Alexander" <alexander.levin@verizon.com>]

On Fri, Sep 02, 2016 at 03:42:15PM -0400, gregkh@linuxfoundation.org wrote:
> 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.

My point was that it seems like most maintainer actually work the other way
around: they may not send things for -rc5/6/7 and would rather hold off on
them until the next merge window. I'm just basing it on an objective count of
stable tagged commits during the merge window vs during release cycles.

What you described would lead to more stable tagged commits during release
cycles, but if you look at the numbers it's very much the other way around.

> > 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 :)

Yes I very much agree with that, I'm just saying that that very first stable
commit usually has the highest amount of fixes to the corresponding mainline
kernel, so I'd never use the mainline kernel until that first "unstable"
release.

-- 

Thanks,
Sasha