| |||||||||||||
|
| |||||||||||||
Stable kernels 2.6.31.6 and 2.6.27.39 releasedStable kernels 2.6.31.6 and 2.6.27.39 releasedPosted Nov 10, 2009 13:34 UTC (Tue) by qg6te2 (guest, #52587)In reply to: Stable kernels 2.6.31.6 and 2.6.27.39 released by patrick_g Parent article: Stable kernels 2.6.31.6 and 2.6.27.39 released Linux 2.6.31 has numerous issues and does not look good as a candidate for long term support or use as a release kernel. There was general agreement on this, the main issues being the number of regressions it shipped with and its generally poor state Huh? So all the recent fix releases, such as 2.6.31.6, mean nothing? Can I have what they're smoking? Given that kernel developers don't seem to care whether the number of regressions reaches zero before making a new release, the statement from Debian's kernel meeting implies that the (still unreleased) 2.6.32 kernel is unuseable by default. Earth shattering news: 2.6.32 is based on 2.6.31.
(Log in to post comments)
Stable kernels 2.6.31.6 and 2.6.27.39 released Posted Nov 10, 2009 13:47 UTC (Tue) by ballombe (subscriber, #9523) [Link]
> Huh? So all the recent fix releases, such as 2.6.31.6, mean nothing? Can I have what they're smoking?
The post you quote is nearly one month old, and 2.6.31.6 was released today...
Stable kernels 2.6.31.6 and 2.6.27.39 released Posted Nov 10, 2009 16:14 UTC (Tue) by hmh (subscriber, #3838) [Link]
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.
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)
>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.
|
|
||||||||||||