Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

Chuck Ebbert cebbert at redhat.com
Tue Sep 7 03:05:29 UTC 2010


On Thu, 02 Sep 2010 18:23:01 -0500
John Morris <jmorris at beau.org> wrote:

> In my case I reported #573135 back in March and stopped taking kernel
> updates. In another month or so I'll boot a live USB stick of F14 and
> see if the bug was fixed and just didn't get closed.  Then it is either
> suck it up and run without security fixes or jump distros.
> 

And in the meantime these patches went into the F12 kernel via
2.6.32-stable, but you weren't even checking the updates:


http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.10:

commit 6279896e0d676c172f50c046064f889185382eac
Author: Henrique de Moraes Holschuh <hmh at hmh.eng.br>
Date:   Thu Feb 25 21:28:56 2010 -0300

    thinkpad-acpi: document HKEY event 3006
    

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.12:

commit 1b0d63f15fb79d0cb840f8b701f343548b5640e8
Author: Henrique de Moraes Holschuh <hmh at hmh.eng.br>
Date:   Thu Feb 25 22:22:22 2010 -0300

    thinkpad-acpi: lock down video output state access
    
    commit b525c06cdbd8a3963f0173ccd23f9147d4c384b5 upstream.
    
    Given the right combination of ThinkPad and X.org, just reading the
    video output control state is enough to hard-crash X.org.
    

> There really needs to be a change of attitude from "Ooh! Shiny!  Ship
> it!" to not shipping new until it at least does everything the old did
> and reverting when serious bugs appear and can't be quickly patched.
> Yes I realize I'm suggesting something that will result in new stuff
> taking longer to arrive.

You're suggesting something that will result in no kernel update ever
being shipped, not even from the -stable kernel series, because even
that has caused some regressions.


More information about the test mailing list