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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Thorsten,

On Thu, Jun 13, 2024 at 10:32:27AM +0200, Thorsten Leemhuis wrote:
> 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 think there's a general agreement that those tags are useful, should
be used, and are already widely used. Reminding everybody, be they
maintainers or not, is fine with me. Making this an extra strict duty
for maintainers, however, is something I can't support. We already have
a bad maintainer burnout problem, and this would make it worse,
resulting in a worse long term outcome in my opinion.

I would be more interested in exploring why regression fixes don't end
up in stable releases in a timely manner, and seeing how we could
improve that at no cost for maintainers. We may even be able to come up
with processes and tools that, when used right, would save time for
maintainers. That would have a higher chance of getting broader
adoption.

> 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. :-/

-- 
Regards,

Laurent Pinchart