Message-ID: <2023061936-eatable-grumbling-f3c1@gregkh>
Date:   Mon, 19 Jun 2023 15:58:40 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux kernel regressions list <regressions@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: JFYI: patches in next that might be good to mainline rather
 sooner than later?

On Mon, Jun 19, 2023 at 02:19:49PM +0200, Thorsten Leemhuis wrote:
> Last year on the maintainers summit we discussed this "delayed stable
> backport" thingy that afaik works something like this:
> 
> Cc: <stable@...r.kernel.org> # after 4 weeks
> 
> Or is it more like this?
> 
> Cc: <stable@...r.kernel.org> # 6.2 [after 4 weeks]
> 
> I think the conclusion was to add this to the documentation, but that
> afaics never happened. If you tell me the format you or your scripts
> expect, I'd be willing to create a patch.

Either of them will work, as my "script" is me reviewing each patch :)

It's rare that I see this, I have been doing it for a few USB patches
recently, but I don't mark them as I know to hold off on stable
integration a bit, but I can't read the minds of other maintainers.

> > The "fixes-only" commits are a bit more interesting, we still have huge
> > swaths of subsystems that refuse to actually tag commits for stable, but
> > luckily developers know to at least put a "Fixes:" tag on their fixes,
> > which help us out in classifying where they should go.
> 
> Various aspects contribute to this, but due to my regression tracking
> efforts two of them jumped to my mind here:
> 
> * A clear statement from Linus wrt to the stable tags in changes that
> fix regressions would be good. E.g. something along the lines of "always
> add a CC: <stable@... tag when fixing a regression caused by change
> mainlined during the past year to ensure the fix reaches the users of
> stable trees quickly".

Sounds good to me for you to say that!  It should happen, but remember
many maintainers still don't want to, or feel they need to, tag anything
for stable.  And that's fine, I can't tell people what to do and the
stable tree stuff was ALWAYS designed to never require maintainers to do
more work than they wanted to.

Hence Sasha's great AUTOSEL work in digging out patches from those
subsystems that do NOT mark anything for stable.

So while we can ask, we can never require.

> * a (big?) part of the problem afaics is that many developers and
> maintainers seem to think that a "Fixes:" tag is enough to ensure a
> backport. You efforts educating them[2] at least from here look a bit
> like a endless game of whac-a-mole, as you sent such mails for quite a
> while already and it seems nothing much has changed. Sometimes I wonder
> if we should spam everyone in MAINTAINERS (and some of the regular
> developers as well?) with a short PSA trying to kill that myth. But I
> don't really like that idea myself. Maybe it would help if Linus
> mentions it two or three times in release announcements?
> 
>   [2] for the unaware and the record, here are two recent ones:
> https://lore.kernel.org/all/2023060703-colony-shakily-3514@gregkh/
> https://lore.kernel.org/all/2023061137-algorithm-almanac-1337@gregkh/

Given that the cc: stable predates the Fixes: tag by years, it's funny
that people don't realize this.

BUT it's the fixes tag that we have been using for those subsystems that
do NOT tag stuff for stable, so I guess when people saw patches flow in,
they just "assumed" that this was the normal process.

So yes, I'll keep reminding people, and Sasha does a great job in
sweeping up the Fixes: only patches, it is never guaranteed that this
will get into a stable release.

Except for a yearly "here is how stable works" email like you say to all
MAINTAINERS, I don't know how it would be any more explicit than what we
have documented today.  Maybe I should do that yearly type of an email,
consider it a christmas card update or something :)

thanks,

greg k-h

Powered by blists - more mailing lists