Re: [MAINTAINERS SUMMIT] [0/4] Common scenario for four proposals regarding regressions

[Thorsten Leemhuis <linux@leemhuis.info>]

On 21.06.24 01:25, Sasha Levin wrote:
> On Thu, Jun 20, 2024 at 12:02:21PM -0400, James Bottomley wrote:
>> Right, but the point I'm making is that even that wider pool doesn't
>> have the app use or hardware breadth of the pool who try out stable.  I
>> also agree the stable users would rather not be testers but given that
>> they are, it's not impossible we could sell them on the idea of testing
>> out .0 to find bugs they would otherwise be finding in .n.
>>
>> After all, given that stable is now delaying backports in the merge
>> window, there should be at least a 2 week period where .0 is it
>> (although it's also the two week period where we're not paying
>> attention ...)
> 
> We also keep the prior kernel alive for a few weeks *after* a merge
> window.
> 
> We understand that X.Y.Z for Z<~5 kernels receive many changes and need
> additional testing, and so users have the option of staying on the Y-1
> kernel for a few weeks until issues with X.Y are settled.
> 
> So yes, users should have "at least two", but really "at least five"
> weeks to find out issues in a post-merge-window release.

Hmmm. Is it really "at least five"? 6.8.12 was the last 6.8.y release
and it came out on 2024-05-30  7:59 UTC in parallel to the 6.9.3 release
I mentioned in another mail yesterday -- and thus also just three and a
half days after 6.10-rc1 was out. And from what I see it also contained
384 patches from the 6.10 merge window where I wonder how much testing
they have seen during that short time-frame.

FWIW, the above and other things I said yesterday may sound like I'm
complaining about the way the stable maintainers work. But to be clear:
Given the circumstances I understand why things are as they are. But to
reduce the risk of regressions in stable trees I wonder if we can
improve the circumstances somewhat, so that the non-urgent patches among
those 384 changes never would have made it to 6.8.y in the first place
-- and only make it to 6.9.y (and earlier longterm series) once they saw
more testing in mainline. Like at least 50 among those 384 changes that
were committed to some subsystem tree during February and March and
therefore took weeks to get mainlined -- and thus are unlikely to be
urgent or crucial (or should have been mainlined way earlier in the
first place). I guess the same applies to many or all of the 189 changes
committed to some tree during April, too. For those from may it's harder
to say without a way to mark the non-urgent ones.

Or do something entirely different. Like "only backport changes quickly
that have a stable tag; everything that has a Fixes: tag is only
backported after it has been in at least three -rc (IOW: two week),
unless someone asked for a quicker backport". But that way we risk that
some urgent fixes lacking a stable tag take too long to get backported.
That sounds like a worse idea to me. #sigh

Ciao, Thorsten