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 wishto keep the .31 kernel alive longer. I am only one person, and can notmaintain 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. Ihave 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 haveno 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. Ihave mentioned it before to a number of people, but don't know if I'vedone any "official" announcement. Things get lost in the lkml volume attimes.