linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ozan Çağlayan" <ozan@pardus.org.tr>
To: Greg KH <greg@kroah.com>
Cc: Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, stable@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	akpm@linux-foundation.org, torvalds@linux-foundation.org,
	stable-review@kernel.org, alan@lxorguk.ukuu.org.uk
Subject: Re: [stable] [0/9] 2.6.31.12-stable review
Date: Sun, 17 Jan 2010 18:07:38 +0200	[thread overview]
Message-ID: <4B5335CA.7080309@pardus.org.tr> (raw)
In-Reply-To: <20100117032319.GA27413@kroah.com>

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


  reply	other threads:[~2010-01-17 16:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-14 22:48 [0/9] 2.6.31.12-stable review Greg KH
2010-01-14 22:46 ` [1/9] fasync: split fasync_helper() into separate add/remove functions Greg KH
2010-01-14 22:46 ` [2/9] hwmon: (adt7462) Fix pin 28 monitoring Greg KH
2010-01-14 22:46 ` [3/9] kernel/signal.c: fix kernel information leak with print-fatal-signals=1 Greg KH
2010-01-14 22:46 ` [4/9] netfilter: ebtables: enforce CAP_NET_ADMIN Greg KH
2010-01-14 22:46 ` [5/9] netfilter: nf_ct_ftp: fix out of bounds read in update_nl_seq() Greg KH
2010-01-14 22:46 ` [6/9] quota: Fix dquot_transfer for filesystems different from ext4 Greg KH
2010-01-14 22:46 ` [7/9] fix braindamage in audit_tree.c untag_chunk() Greg KH
2010-01-14 22:46 ` [8/9] fix more leaks in audit_tree.c tag_chunk() Greg KH
2010-01-14 22:46 ` [9/9] ipv6: skb_dst() can be NULL in ipv6_hop_jumbo() Greg KH
2010-01-16 19:03 ` [0/9] 2.6.31.12-stable review Ozan Çağlayan
2010-01-16 19:07   ` H. Peter Anvin
2010-01-17  3:23   ` [stable] " Greg KH
2010-01-17 16:07     ` Ozan Çağlayan [this message]
2010-01-17 16:18       ` Greg KH
2010-01-17 16:30         ` Ozan Çağlayan
2010-01-17 18:02         ` Henrique de Moraes Holschuh
2010-01-18  5:42           ` Greg KH
2010-01-18  7:49         ` [Stable-review] " Nikola Ciprich
2010-01-19  4:07           ` [stable] [Stable-review] " Greg KH
2010-01-19 23:02     ` [stable] " Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B5335CA.7080309@pardus.org.tr \
    --to=ozan@pardus.org.tr \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable-review@kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).