[MAINTAINERS SUMMIT] [2/4] Ensure recent mainline regression are fixed in latest stable series

[Thorsten Leemhuis <linux@leemhuis.info>]

I propose we extend the implications of the "no regressions" rule so
that mainline developers must ensure fixes for recent mainline
regression make it to the latest stable series.

[FWIW, yes I'm well aware that this is a bold proposal; I also have no
idea how even Linus thinks about the idea. But I'm bringing it up anyway
to at least discuss this, as from my point of view it would fix what I
consider a kind of loophole regarding our "no regressions" rule -- at
least from the point of view of the users.]

We might have a "no regressions" rule, but nothing currently makes sure
that regressions introduced recently are fixed in a timely manner in the
latest stable series. Hence a fix for a regression found just hours
after a new mainline release (say 6.7) might only reach users weeks
later with its successor (e.g. 6.8) -- or in unlucky cases when the fix
is only merged in the next merge window and not backported only with the
second successor (6.9). The example scenario at the start of this thread
illustrates that in more details.

To improve this situation I propose we add a rule like the following
somewhere:

"""Developers must ensure that fixes for regressions introduced in the
last development cycle make it to the latest stable series -- typically
by adding 'Fixes:' and 'CC: <stable…' tags to the patch description's
footer."""

I know I'm asking a lot here, especially from the file system folks due
to the testing this will require. And I fully understand the
participation in stable maintenance always has been and still is
optional for mainline developers -- and that this would change it.

But I'm bringing this up anyway, as users afaics expect "fix recently
introduced problems with new minor releases', as it is a pretty normal
thing in most other FLOSS projects that have minor releases. A lot of
kernel developers are already doing what I proposed anyway. It could be
viewed as fair to our user base, too. And without it the "no
regressions" rule might be considered hollow.

Note, to quickly fix such regression in the latest stable series such
regressions obviously must first be fixed in a timely manner in
mainline; that aspect is ignored here, as proposals 3/4 of this thread
will covers that.

Another note: the "Expectations and best practices for fixing
regressions" in Documentation/process/handling-regressions.rst (see
[1/4] kind of covers this already. But it does not use the term "must";
at the same time the scope is bigger, too, which is partly due to a
statement from Linus[1]: """If a regression made it into a proper
mainline release during the past twelve months, ensure to tag the fix
with "Cc: stable@vger.kernel.org", as a "Fixes:" tag alone does not
guarantee a backport. Please add the same tag, in case you know the
culprit was backported to stable or longterm kernels.""""
[1]
https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/

Side note: due to the [1] above the rule this messages proposes above
maybe needs 's/introduced in the last development cycle/introduced in
mainline versions released during the past 12 months/" (or five or six
releases instead, as that is easier to keep track of?). But I guess with
that this proposal likely would be even less welcomed. :-/