[lkml]   [2010]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [stable] [0/9] review
    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 to 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 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

    Please send 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 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 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

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


    greg k-h

     \ /
      Last update: 2010-01-17 17:21    [W:0.035 / U:18.964 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site