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

Steven Rostedt
2024-06-14T00:50:33Z

On Thu, 13 Jun 2024 14:28:48 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> Hi Thorsten,

Hi Thorsten,

I'm sure you had your flame suit on when you posted this ;-)

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

When reading this thread I was thinking somewhat the same thing. I like
knowing about regressions, and having a way to track them. What would
really be helpful is to have more ways to be able to catch regressions,
and possibly better tooling to find where they started.

I think the focus on this is to make it easier for maintainers to see
there's a regression and where it started. But there should not be any
requirement that the maintainer must deal with it. It could be
something that others working in that subsystem could track. This could
be used for those that want to start kernel development and keep asking
us "do you have any todo list?". Well, this looks like the perfect todo
list for people to take on.

-- Steve