Re: [stable] [0/9] 2.6.31.12-stable review

[Greg KH <greg@kroah.com>]

On Sun, Jan 17, 2010 at 06:07:38PM +0200, Ozan ??a??layan wrote:
> 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.

Distros can easily add additional patches to their kernel if they wish
to keep the .31 kernel alive longer.  I am only one person, and can not
maintain 3 different kernel trees and remain sane.

> 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 :)

You aren't the first to think that .31 would be a "long term" kernel.  I
have never stated this, and I wonder where that rumor came from.

> 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),

Only with debug option enabled.

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

Please send stable@kernel.org fixes for these problems, otherwise I have
no idea that they need to be included.

> *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.

bugs happen.

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

Yes, I will be maintaining the .32 kernel in a "long-term" manner.  I
have mentioned it before to a number of people, but don't know if I've
done any "official" announcement.  Things get lost in the lkml volume at
times.

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

Hey, that's my day-job, I know the problems well.

Ok, to help you solve this issue, I will be willing to do one more .31
release after this one.  Just send me the git commit ids of the patches
you wish for me to include, and I will do so.

Sound good?

thanks,

greg k-h