Re: Regressions in stable releases

[Sasha Levin <sashal@kernel.org>]

On Thu, Aug 05, 2021 at 08:30:55PM +0200, Willy Tarreau wrote:
>On Thu, Aug 05, 2021 at 10:29:49AM -0700, Guenter Roeck wrote:
>> > It looks like a typical "works for me" regression. The best thing that
>> > could possibly be done to limit such occurrences would be to wait "long
>> > enough" before backporting them, in hope to catch breakage reports before
>> > the backport, but here there were already 3 weeks between the patch was
>> > submitted and it was backported.
>>
>> No. The patch is wrong. It just _looks_ correct at first glance.
>
>So that's the core of the problem. Stable maintainers cannot be tasked
>to try to analyse each patch in its finest details to figure whether a
>maintainer that's expected to be more knowledgeable than them on their
>driver did something wrong.
>
>Then in my opinion we should encourage *not* to use "Fixes:" on untested
>patches (untested patches will always happen due to hardware availability
>or lack of a reliable reproducer).
>
>What about this to try to improve the situation in this specific case ?

No, please let's not. If there is no testing story behind a buggy patch
then it'll explode either when we go to the next version, or when we
pull it into -stable.

If we avoid taking groups of patches into -stable it'll just mean that
we end up with a huge amount of issues waiting for us during a version
upgrade.

Yes, we may be taking bugs in now, but the regression rate (according to
LWN) is pretty low, and the somewhat linear distribution of those bugs
throughout our releases makes them managable (to review when they're
sent out, to find during testing, to bisect if we hit the bug).

As Guenter points out, the path forward should be to improve our testing
story.

-- 
Thanks,
Sasha