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: <Pine.LNX.4.64.0704260133271.28708@iabervon.org>
Date:	Thu, 26 Apr 2007 02:46:08 -0400 (EDT)
From:	Daniel Barkalow <barkalow@...ervon.org>
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

On Thu, 26 Apr 2007, Adrian Bunk wrote:

> Number of different known regressions compared to 2.6.20 at the time
> of the 2.6.21 release:
> 14

I count 13. (v2) had 15 items, of which 2 were subsequently fixed or found 
to be inapplicable.

> 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

The -stable team can presumably take care of these in 2.6.21.1, right? 
That leaves 10 that need developer attention.

 John Stultz seems to be taking care of 3 of them.

 Oliver Neukum has 1.

 2 are particular drivers (ali_pata and rtl8139, according to the 
 reports).

 2 seem to be ACPI-related; at least one has a candidate patch now.

 1 seems to be an ALSA problem.

 1 is STD and being debugged.

It looks like all of the known regressions are being worked on, and 
getting fixes in for them is -stable material at this point. Furthermore, 
it doesn't look to me like anyone who is needed for dealing with these 
regressions is trying to get stuff into the 2.6.22 merge window.

I think it's clear that this is the right point for Linus to start the 
2.6.22 cycle and leave the rest of the 2.6.21 work to the -stable team, 
who are the experts of taking care of this sort of stuff. Furthermore, it 
seems like -rc testers at this point have found everything in 2.6.21-rc 
they're going to, so, again, it's time for new regressions. Personally, I'd 
vote for having Linus leave off at 2.6.X-final, and have 2.6.X be the 
first -stable release of the series, where the remaining known regressions 
get fixed, but that's an issue of nomenclature, not development process.

I think you've allowed for a well-tested 2.6.21, and a good chance of a 
2.6.21.1 or .2 with no known regressions against 2.6.20, which seems to me 
like you succeeded as far as everything except making Linus a release 
engineer.

	-Daniel
*This .sig left intentionally blank*
-
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/