| |||||||||||||
Achieving high-quality major releases of the Linux kernelAchieving high-quality major releases of the Linux kernelPosted Dec 4, 2004 4:33 UTC (Sat) by jreiser (subscriber, #11027)Parent article: Kernel prepatch 2.6.10-rc3 ... the only tool we have to ensure this is longer stabilisation periods. What? Don't the thousands of automated test cases that have been accumulated during more than a dozen years of development suffice? :-)
(Log in to post comments)
Achieving high-quality major releases of the Linux kernel Posted Dec 4, 2004 15:38 UTC (Sat) by ncm (subscriber, #165) [Link] Now, now, John, let's not be nasty.
One might suspect that some company (IBM, SGI, even RH or Suse) would have its own set of regression tests. However, there would seem no advantage in keeping them secret, and enormous advantages to not keeping them secret. We can conclude with some confidence that there is no such secret test suite.
You mean, like the LTP? Posted Dec 4, 2004 16:40 UTC (Sat) by louie (subscriber, #3285) [Link] LTP is IBM's effort at this. But I presume it has the same problems keeping up with the pace of development that every other non-core developer has.
Achieving high-quality major releases of the Linux kernel Posted Dec 5, 2004 17:14 UTC (Sun) by job (guest, #670) [Link] ... and let's not forget that if Linux was developed with the goal ofbecoming the catch-all UNIX kernel it is today, it would be forever stuck in political bickering, bad architecture decisions, and the like. It would not have attracted developers continously but when it's "ready" (which would be never).
Achieving high-quality major releases of the Linux kernel Posted Dec 4, 2004 19:37 UTC (Sat) by iabervon (subscriber, #722) [Link] Those are great for testing everything that's broken before. But they still have to have a variety of actual users test for things that just broke for the first time. Then there are all of the things that only break on computers with unexpected hardware combinations (IIRC there was a bug where the system thought it was out-of-memory when it was a NUMA system with a node that lacked some kind of memory entirely, which happened on some moderately common system).
Then, of course, there are the things that aren't strictly-speaking wrong, but cause common code to behave very poorly or trigger bugs in userspace needlessly.
Unfortunately, people aren't satisfied simply by a huge number of possible bugs the kernel doesn't have...
Achieving high-quality major releases of the Linux kernel Posted Dec 6, 2004 17:41 UTC (Mon) by cliffman (guest, #13144) [Link] I've said it before, and I'll say it again. We (OSDL) have machines, and code. We run automated tests, everyday. Results, code, and scripts are all publically available, here: http://www.osdl.org/lab_activities/kernel_testing/stp
and here:
We keep _nothing secret around here. it's all open. The problem is getting people to look at the test results, because OSDL doesn't have that many people available to do this. ( There's only three of us in tesdev, and we have other responsibilities. ) If _you have test code you want run, we'll help you add it to our rig. If _you would like to look at, analyse and comment on tests already rum, we're here to help. If you have kernel patches you want tested, our robots are here to serve you.
|
|||||||||||||