Re: [MAINTAINERS SUMMIT] [4/4] Discuss how to better prevent backports of commits that turn out to cause regressions

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2024-06-13 at 10:42 +0200, Thorsten Leemhuis wrote:
> The scenario shown at the start of the thread illustrates a problem I
> see frequently: commits with a Fixes: tag end up in new to stable
> series releases just days after being mainlined and cause regressions
> -- just like they do in mainline, which just was not known yet at the
> time of backporting. This happens extremely often right after merge
> windows when huge piles of changes are backported to the stable trees
> each cycle shortly after -rc1 is out (which even some kernel
> developers apparently are somewhat afraid to test from what I've
> seen).

I haven't really observed this for curated fixes.  For most subsystems,
patches with Fixes tags that are cc'd to stable tend to go steadily
outside the merge window.  Obviously a few arrive within it, but
usually at roughly the rate they arrive outside it.

What I observe in the merge window is huge piles of patches go into
stable *without* a cc:stable tag from the autosel machinery (and quite
a few even without fixes: tags).

So this does beg a couple of questions:

Since you have the figures, what's the proportion of regressions caused
by backports to stable without cc:stable tags?

Could we fix a lot of this by delaying autosel?  It tends to ramp up in
the merge window when everyone is concentrating on other things, so any
regressions it causes naturally get ignored for a couple of weeks.

James