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.
