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

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Jun 13, 2024 at 07:58:58AM -0400, James Bottomley wrote:
> 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).

The merge window has a huge number of patches sent to Linus _with_ a
Fixes: tag, or a cc: stable tag.  It's our busiest time of the cycle by
far.  But overall, it's still a smaller % of the patches that end up in
the tree overall, so it looks big to us and everyone else, but it's
really not.  The % going in during the end -rc cycles is still higher,
as it rightfully should.

Only patches I see in our trees that do not come from autosel without
fixes: tags should have a stable-dep-of: tag, OR it is because someone
has sent it to us for explicit inclusion.  If you see stuff that does
not meet that criteria, please let us know.

thanks,

greg k-h