From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 383F5891 for ; Thu, 3 May 2018 15:01:12 +0000 (UTC) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0121.outbound.protection.outlook.com [104.47.37.121]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0DD736BF for ; Thu, 3 May 2018 15:01:10 +0000 (UTC) From: Sasha Levin To: Willy Tarreau Date: Thu, 3 May 2018 15:01:08 +0000 Message-ID: <20180503150104.GL18390@sasha-vm> References: <20180501163818.GD1468@sasha-vm> <20180502195138.GC18390@sasha-vm> <20180503000620.GA29205@thunk.org> <20180503144612.GJ18390@sasha-vm> <20180503145205.GD23311@1wt.eu> In-Reply-To: <20180503145205.GD23311@1wt.eu> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <55B9CE414D3E7D428BD0CEF05328F8F1@namprd21.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "linux-kernel@vger.kernel.org" , "ksummit-discuss@lists.linuxfoundation.org" , Greg KH Subject: Re: [Ksummit-discuss] bug-introducing patches List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.=