| |||||||||||||
Is the kernel development process broken?Is the kernel development process broken?Posted Mar 9, 2005 17:20 UTC (Wed) by jwb (guest, #15467)Parent article: Is the kernel development process broken?
Is the extra-stable tree going to merge up to 2.6.x for every value of x? If so I don't see the value, because that would mean the 2.6.x.y kernel contains all the problems of 2.6.x, minus a few fixes. There's only so many fixes you can get in y, and none of them are going to address the fact that Linus replaced the SCSI layer and the MMU subsystem between x-1 and x.
I used to test a lot of kernels, but eventually the problems I was seeing became untestable. The problems tend to crop up on the larger multiprocessor machines with significant i/o abilities and vast storage under heavy load, and unfortunately I don't have a "spare" one of those I can use for purposes of Linux kernel quality assurance.
Maybe there's not enough new features and obnoxious bugs to cause people to try out the kernels. I know when my hardware was unsupported I would try every -mm, -ac, -aa, -et al release to see if it fixed whatever problem I was having. But now that everything works, I'd rather not change.
Indeed, the opposite is now true. Since everything works correctly, I'm afraid to try new releases. I moved from 2.6.8 to 2.6.10-rc on a desktop machine of mine, and so many things were broken that I just gave up and went back to the previous.
(Log in to post comments)
Is the kernel development process broken? Posted Mar 9, 2005 23:28 UTC (Wed) by PaulDickson (subscriber, #478) [Link] Is the extra-stable tree going to merge up to 2.6.x for every value of x? If so I don't see the value, because that would mean the 2.6.x.y kernel contains all the problems of 2.6.x, minus a few fixes. I think you have it mentally backword: the 2.6.x.y kernel contains 2.6.x, plus a few fixes. Which is the same except for atitude. y can continue to increment even after 2.6.x+1 is released (which might happen if 2.6.x+1 is not considered to be stable enough). I used to test a lot of kernels, but eventually the problems I was seeing became untestable. The problems tend to crop up on the larger multiprocessor machines with significant i/o abilities and vast storage under heavy load, and unfortunately I don't have a "spare" one of those I can use for purposes of Linux kernel quality assurance. Is it any wonder unreported bugs might persist? Especially on uncommon machines that developers might not have ready access. And while you may not have a spare machine, you are testing the kernels. Even if you only use kernels from a distribution for your exact system, you'll still have to do this testing, except in that case you'd send the report back to the distribution's creator. Both positive and negative reports are always helpful, but more detail is better for negative results.
|
|||||||||||||