linux-kernel - Re: Linux 2.6.21

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4630E00B.3090502@tmr.com>
Date:	Thu, 26 Apr 2007 13:23:23 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Adrian Bunk <bunk@...sta.de>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.21

Adrian Bunk wrote:
> On Wed, Apr 25, 2007 at 08:29:28PM -0700, Linus Torvalds wrote:
>> ...
>> So it's been over two and a half months, and while it's certainly not the 
>> longest release cycle ever, it still dragged out a bit longer than I'd 
>> have hoped for and it should have. As usual, I'd like to thank Adrian (and 
>> the people who jumped on the entries Adrian had) for keeping everybody on 
>> their toes with the regression list - there's a few entries there still, 
>> but it got to the point where we didn't even know if they were real 
>> regressions, and delaying things further just wasn't going to help.
>> ...
> 
> 
> Number of different known regressions compared to 2.6.20 at the time
> of the 2.6.21 release:
> 14
> 
> Number of different known regressions compared to 2.6.20 at the time
> of the 2.6.21 release that were first reported in March or earlier:
> 8
> 
> Number of different known regressions compared to 2.6.20 at the time
> of the 2.6.21 release with patches available at the time of the 2.6.21 
> release [1]:
> 3
> 
> What I will NOT do:
> Waste my time with tracking 2.6.22-rc regressions.
> 
> 
> We have an astonishing amount of -rc testers, but obviously not the 
> developer manpower for handling them.
> 
> If we would take "no regressions" seriously, it might take 4 or 5 months 
> between releases due to the lack of developer manpower for handling 
> regressions. But that should be considered OK if avoiding regressions 
> was considered more important than getting as quick as possible to the 
> next two week regression-merge window.
> 
> But releasing with so many known regressions is insulting for the many 
> people who spent their time testing -rc kernels.
> 
Without someone holding Linus feet to the fire the next release may be a 
real POS. I think you have done the perfect job, identifying the show 
stoppers, quantifying the obscure and minor regressions, and serving to 
give testing targets as purported fixes are applied.

I don't think you should judge your work by leaving some targets for 
-stable and 2.6.22, but rather from the number of problems you detected, 
documented, and caused to be addressed.

If it were my week to be God, I would insist that the rcN to final step 
was regressions-only, and that all regressions be classified as (a) 
acceptable results of changes to fix other problems, (b) must be fixed 
before release, or (c) obscure enough to tolerate for a short time, must 
be fixed in stable and mainline before N+1 release.

Measuring releases or your own value against perfection is thankless!

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/