| |||||||||||||
NFS bugNFS bugPosted Aug 19, 2004 20:10 UTC (Thu) by NAR (subscriber, #1313)In reply to: NFS bug by jeremiah Parent article: The end of the fcntl() method Anyone ever try to get unit testing into the kernel, or some of it's more critical subsystems? It depends on what you call "more critical". It can really slow down the release process, if you add lots of unit testing. On the commercial project where I work, the running of the automated tests take more time than the actual compilation. An in my opinion, we have way too few tests.
(Log in to post comments)
NFS bug Posted Aug 20, 2004 14:02 UTC (Fri) by jeremiah (subscriber, #1221) [Link] True, but the question is, what is causing us to relase more updates/patches. bug fixes or enhancements. To me it seems that there are ussally some nice enhancments that add a few bugs, and a much bigger amount of bug fixes. Would most of these bugs that are being addressed never have made it into the mainline kernel if unit testing was in place. Would it save developer time? I think it would help is some areas where people are tring out large patches, or reworking whole subsystems, VM etc. You can run the test, and know that what ever you did didn't screw anything up. As to the really slow down releases thing, I know time to run the test would be slower, but not every one needs to run the test, just the maintainer and the original developer, and perhaps Linus right before it goes out.
To argue against myself here though, the amount of effort required to set up testing would drive me insane quite quickly. Much less backfit that much testing onto a moving target like the kernel.
NFS bug Posted Aug 21, 2004 0:22 UTC (Sat) by khim (subscriber, #9252) [Link] There are more oportant thing. "Brown paper bug" releases do happen from time to time, no doubt about it - but most bug-fixes are covering some previously unknown case! Some improper flags combination, or some obscure version of system call, etc. Any automated testing is useless against it.
|
|||||||||||||