LWN.net Logo

Stable kernels 2.6.31.6 and 2.6.27.39 released

Stable kernels 2.6.31.6 and 2.6.27.39 released

Posted Nov 10, 2009 16:14 UTC (Tue) by hmh (subscriber, #3838)
In reply to: Stable kernels 2.6.31.6 and 2.6.27.39 released by qg6te2
Parent article: Stable kernels 2.6.31.6 and 2.6.27.39 released

That's not how it works.

2.6.30 was Bad, and coupled with some other Bad Stuff that crept in during 2.6.31-rc, the result was a sadist kernel that liked to deal major pain (2.6.31).

2.6.31.6 is probably getting into usable territory again, but it still has some important stuff waiting for fixes to land. 2.6.31.7/.8 will probably be acceptable.

These stable releases mean a LOT, they effectively transformed something that was sheer torture (2.6.31) into something one can use with minor pain (2.6.31.4), and now it should be already into "something one can use with occasional minor pains". When the e1000e and page reclaim fixes land in the next stable releases, 2.6.31.y should be almost painless for most users.

By the time 2.6.32 ships, the worst of the fallout from 2.6.30 and 2.6.31 will have been fixed for good (including the stuff that one doesn't fix on -stable releases due to complexity or risk), so, if whatever breakage gets introduced during 2.6.32-rc is not especially bad, it has some chance of being a good kernel.

The Debian kernel maintainers know what they're talking about.


(Log in to post comments)

Stable kernels 2.6.31.6 and 2.6.27.39 released

Posted Nov 10, 2009 16:55 UTC (Tue) by nix (subscriber, #2304) [Link]

It massively corrupted my filesystem last night, but I think this was my fault, with what was in hindsight a horribly buggy tuxonice-debugging patch, which broke proper suspension of the block devices, following which ext4 tried to write to them, stamped on its own superblock then panicked and rebooted, leaving me with a desynchronized RAID array and all mounted filesystems with badly mashed block group descriptors and superblocks.

But fsck fixed them all flawlessly (zero differences from backup, I owe tytso yet another beer, by this point I owe him so many he could kill himself with alcohol on my tab) and I blame my own broken patch anyway.

Stable kernels 2.6.31.6 and 2.6.27.39 released

Posted Nov 11, 2009 12:24 UTC (Wed) by jengelh (subscriber, #33263) [Link]

Up a number of parents:
>that the number of patches and/or important issues in 2.6.31 exceeds that for recent releases. Is this true?

Statistically, this seems to be the case.

v2.6.16.62: 1053 commits within 854 days (avg=1.23)
v2.6.27.37: 1298 commits within 367 days (avg=3.53)
v2.6.28.10: 613 commits within 128 days (avg=4.78)
v2.6.29.6: 383 commits within 101 days (avg=3.79)
v2.6.30.9: 436 commits within 118 days (avg=3.69)
v2.6.31.6: 372 commits within 61 days (avg=6.09)

>If so, are there any lessons to be learned?

Also see it from the other side: rather than 2.6.31 being overly buggy, we just give it more bugfixing love than the previous ones.

Stable kernels 2.6.31.6 and 2.6.27.39 released

Posted Nov 13, 2009 6:52 UTC (Fri) by njs (subscriber, #40338) [Link]

Your statistics are only valid if the patch rate for each stable series is constant over time. It seems more likely that patches flow in the fastest at the beginning of the stable series, and then the rate drops off over time. If that's the case, then your calculation will always show the most recently released kernel as being the worst, because it's the one that's still in that early part of the cycle. Better would be to compare the same period (the first 61 days) of each kernel.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds