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: <4B5335CA.7080309@pardus.org.tr>
Date:	Sun, 17 Jan 2010 18:07:38 +0200
From:	Ozan Çağlayan <ozan@...dus.org.tr>
To:	Greg KH <greg@...ah.com>
CC:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	stable@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	stable-review@...nel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [stable] [0/9] 2.6.31.12-stable review

Greg KH wrote:
> On Sat, Jan 16, 2010 at 09:03:52PM +0200, Ozan ??a??layan wrote:
>> Greg KH wrote:

> 
> As this is going to be the last .31 release, and all users should really
> be moving to .32, I'm not going to worry about this one.  Is that ok
> with you?
> 
> thanks,

Personally I really don't like the idea of "all users should really be moving to .3x" which is true
for individual bleeding edge users which compiles and uses their own kernel but there are still distributions
around (as well as the one that I'm trying to maintain the kernel part) which ships 2.6.31.

Every distribution has a release policy and switching from .3x to .3(x+1) on the road isn't sometimes desirable because
of the regression risks. I can't risk to switch to .32 as I'm still seeing very very serious regression reports on LKML.

We just switched from 2.6.30.10 to 2.6.31.9 because I thought that it was stabilized and
I was hoping that .31 will be a long term maintained release :) Then the next day
I saw the announcement from you saying that 2.6.31.10 will be the last release of .31 series :)

I spotted 3 very annoying regressions in a 3-day period just after switching to 2.6.31:
 - boot hangs with AMD Athlon XP processors (#15075),
 - shutdown hangs on some *apparently* Pentium 4 processors (#15073),
 - Governor failures on some systems because of BUG in MCE code (#14521)

The 1st and the 3rd one were injected during 2.6.31 merge window, so they were regressions that should have been caught already
but to not fix them in 2.6.31.y would be an option as they were always in 2.6.31.y from 2.6.31 to 2.6.31.11.

*but*

The commit causing the 2nd one was accepted during 2.6.31.10 stable review. To accept a bugfix which causes a more serious regression
is somewhat inacceptable for me. You announce the end-of-life of 2.6.31 with 2.6.31.10 with a really serious regression injected.

I don't try to blame anyone as I really really appreciate the work done by all the people in this list but unless some release policy
isn't written for kernel releases, there will always be such annoyances :)

For example, I'm hopelessly waiting for a long-term-supported kernel like .27. Was it because someone liked the number 27 or something else?
Will it happen again? If yes will this decision made public before the release?

Again, please please don't take the whole e-mail personal, I'm just describing a downstream kernel package maintainer's problems :)

Thanks,
Ozan Caglayan
Pardus Linux -- http://www.pardus.org.tr/eng

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ