Re: [Ksummit-discuss] bug-introducing patches

[Sasha Levin <Alexander.Levin@microsoft.com>]

On Thu, May 03, 2018 at 04:52:05PM +0200, Willy Tarreau wrote:
>On Thu, May 03, 2018 at 02:46:14PM +0000, Sasha Levin wrote:
>> I'll work on breaking up the 4.16 commits into categories, but one
>> interesting statistic I've noticed while starting the work is:
>>
>> Fixes in -rc cycles:
>> rc1 68
>> rc2 147
>> rc3 88
>> rc4 121
>> rc5 40
>> rc6 193
>> rc7 98
>>
>> Average days in -next, for a fix, per -rc cycle:
>> rc1 27.25
>> rc2 21.4286
>> rc3 22.5114
>> rc4 18.281
>> rc5 14.65
>> rc6 12.6166
>> rc7 8.70408
>>
>> Fixes for bugs not introduced in current merge window:
>> rc1 40
>> rc2 113
>> rc3 61
>> rc4 79
>> rc5 25
>> rc6 139
>> rc7 72
>>
>> So for some reason, there is a rush to push fixes for older bugs (that
>> were not introduced in the current merge window) to the point that rc7
>> commits that only existed for a few days are merged in to address older
>> bugs.
>
>IMHO it's because it's the time it takes for users to start to trust the
>3rd or 4th stable release of the previous version, to switch to it, to
>face a bug, to report it, and for the maintainer to write a fix.
>
>I wouldn't be much surprised if you'd find that among those not introduced
>in the current merge window, many were introduced in the previous release.

Interesting. Here it is for v4.16-rcX fixes that fix something
introduced before v4.14:

rc1 30
rc2 87
rc3 51
rc4 68
rc5 23
rc6 113
rc7 61

So I'm not sure if what you described is really the case.