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

Thorsten Leemhuis
2024-06-13T08:34:19Z

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