Re: [MAINTAINERS SUMMIT] [4/4] Discuss how to better prevent backports of commits that turn out to cause regressions

[Sasha Levin <sashal@kernel.org>]

On Thu, Jun 13, 2024 at 10:42:01AM +0200, Thorsten Leemhuis wrote:
>I would like to discuss how to better prevent backports of mainline
>commits to stable that turn out to cause regressions.

If you can tell us which backports cause regression we promise not to
backport them :)

But more seriously:

>* For patches that are tagged for backporting it's easy to for
>developers to influence the timing, as they can use a stable tag like
>`Cc: <stable@vger.kernel.org> # after -rc4` to delay backporting (see
>Documentation/process/stable-kernel-rules.rst for details). But for

We can delay, but in practice many of the regressions are discovered
*because* they land in stable. There is relatively little testing on -rc
releases.

I'd argue that in most cases, delaying until a later point in time will
just mean that the issue is discovered later, which isn't helpful...

[ snip ]

>* We could ask the stable team to only backport changes once they have
>been in mainline for a certain time (something like "at the earliest two
>weeks after the change was present in a mainline release or

We could, but is the net result positive? This also means that fixes for
real issues take longer to get to users.

It would make sense if most backports cause a regression. Is it the
case?

>pre-release"?). But to not delay urgent fixes we then would need
>developers to mark the urgent ones somehow. That is likely a hard sell,
>but maybe less so then what the previous point outlined; untangling
>could help here, too.

I'd argue that even developers don't necessarily know if something is
"urgent" or not. Heck, what does "urgent" mean? There are so many
usecases for the kernel that it's impossible to define what is urgent
and what is not.

>* Maybe convince the stable team to consider all commits with just a
>Fixes: tag as "non urgent", if they were merged during a merge window
>with a committer (or author?) date from before the merge window -- and
>then only backport them after -rc4 to ensure they got at least three
>weeks of mainline testing before they are backported. This is imperfect
>and has downsides, but would be relatively simple to realize.

The tricky part here is that we can't rely on stable tags for importance
determination. Individuals and subsystems simply don't add stable tags
because they don't want to, not because their commits are not important
or urgent.

>* We could extend the Fixes tag in a fashion similar to the stable tag
>(see above) to establish something like `Fixes: cafec0cacafe ("foo: bar:
>foobar baz") # after -rc4 if considered backportworthy` -- but some of
>these lines will become awfully long (they already are occasionally even
>without this add-on note).

See above :)

-- 
Thanks,
Sasha