| |||||||||||||
Not a release cycle length problemNot a release cycle length problemPosted May 3, 2007 18:12 UTC (Thu) by giraffedata (subscriber, #1954)In reply to: Not a release cycle length problem by davecb Parent article: A tale of two release cycles
As it's mildly hard to get developers into QC, the company makes working in the QC process an unofficial prerequisite to becoming a member of the kernel team Sometimes, a company just makes QC work an official prerequisite of collecting one's paycheck; i.e. it hires testers for whatever they cost. The reason the Linux kernel can't use this well-worn strategy for eliminating bugs is that the special economics of open source and community development don't provide a way to get people to do all that boring alpha testing (testing for the sake of testing) and debugging. So we've been experimenting for years with release cycle lengths, bug tracking systems, etc. to try to find another way.
(Log in to post comments)
Not a release cycle length problem Posted May 3, 2007 18:38 UTC (Thu) by davecb (subscriber, #1574) [Link] I think we're in violent agreement (;-)) I noticed people break into Linux kernel hacking via the kernel janitors effort, and into at least one non-Linux kernel team by fixing bugs and escalations, so I speculated one might invite people to look at regressions as a good way of learning the newest code to go into the kernel. --dave
Not a release cycle length problem Posted May 3, 2007 19:14 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > The reason the Linux kernel can't use this well-worn strategy for> eliminating bugs is that the special economics of open source and > community development don't provide a way to get people to do all that > boring alpha testing
It seems Adrian complains the alpha testing part is done. What's not done is exploiting all the testing reports.
Not a release cycle length problem Posted May 3, 2007 22:05 UTC (Thu) by giraffedata (subscriber, #1954) [Link] The reason the Linux kernel can't use this well-worn strategy for eliminating bugs is that the special economics of open source and community development don't provide a way to get people to do all that boring alpha testingIt seems Adrian complains the alpha testing part is done. What's not done is exploiting all the testing reports. Chopping the quote where you do, it looks like you're disagreeing. The end of that sentence is "and debugging." I assume it's the debugging part that nobody is signing up for. I also strongly suspect that in the cases that concern Adrian, the testing done was beta testing, which engineers don't find nearly so objectionable. Beta testing is where you fire up the new code and try to use it for real work. Alpha testing is where you simulate using the code, for no gain other than flushing out bugs in it. That's what's boring enough that engineers seem to have to be paid to do it.
|
|||||||||||||