Re: [MAINTAINERS SUMMIT] [3/4] Elevate handling of regressions that made it to releases deemed for end users

["Liam R. Howlett" <Liam.Howlett@oracle.com>]

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [240613 07:35]:
> Hi Thorsten,
> 
> On Thu, Jun 13, 2024 at 10:34:17AM +0200, Thorsten Leemhuis wrote:
> > I propose we elevate fixing of mainline regressions that made it to
> > releases deemed for end users by setting a target to ideally mainline a
> > fix (which might be a revert) within two weeks after the culprit was found.
> > 
> > That IMHO would lessen one of the big pain points for users regarding
> > regressions, as quite a few make it into proper release and then take
> > quite a while to resolve (as shown in the scenario in the mail at the
> > start of this thread). So much so that quite a few users afaics doubt
> > that we take our "no regression" rule seriously.
> > 
> > This is why I'd like to see such situations resolved even faster than
> > regression that happen just in development kernels. "Expectations and
> > best practices for fixing regressions" in
> > Documentation/process/handling-regressions.rst (see [1/4] in this
> > thread) kind of covers this already:
> > 
> > """Expedite fixing mainline regressions that recently made it into a
> > proper mainline, stable, or longterm release (either directly or via
> > backport). [...] Aim to mainline a fix by Sunday after the next, if the
> > culprit made it into a recent mainline, stable, or longterm release
> > (either directly or via backport); if the culprit became known early
> > during a week and is simple to resolve, try to mainline the fix within
> > the same week. [...]"""
> > 
> > I'd like to make the language somewhat stronger.
> > 
> > """Handle mainline regressions that recently made it into a proper
> > mainline, stable, or longterm release (either directly or via backport)
> > with an even higher priority and try to fix them as fast as possible.
> > [...] Aim hard to mainline a fix by Sunday after the next, if the
> 
> Are we really telling people, some of them contributing in their spare
> time, that they have to work during weekends ?
> 
> I don't think piling pressure will help. What could help is to reduce
> pressure on already overloaded maintainers, to give them more time to
> handle regressions. There have been multiple discussions about
> co-maintainance models over the past few years, and some subsystems are
> (slowly) moving forward. I would be more interested in participating in
> that effort. It otherwise feels like we would just add pressure on an
> already overloaded system, without caring that the system has no
> reasonable way to absorb that pressure.
> 
> > culprit made it into a recent mainline, stable, or longterm release
> > (either directly or via backport); try to mainline the fix within the
> > same week, if the regression apparently bothers quite a few users or if
> > the problem with the culprit became known on a Monday or Tuesday."""

Yes, this is the worst idea of all the really bad ideas in this set.

They are so bad that it seems like the point is to actively damage the
community.  Either people will leave, won't join, or it will stall
development in fears of retribution and/or punishment.

Regards,
Liam