Zero bugs (was Re: (Short?) merge window reminder)
From: Valdis . Kletnieks
Date: Fri May 27 2011 - 10:29:38 EST
On Thu, 26 May 2011 22:44:24 PDT, Keith Curtis said:
> However, it is common in companies to make an effort to get towards
> zero bugs. Zero bugs is impossible, and that is a philosophical
> discussion. If you look through your current list of bugs, nearly
> every one looks scary to me and important to someone. You currently
> have 2,800 active bugs (http://bit.ly/LinuxBugs) The last time I
> looked, I found the median age was 10 months. In general, bugs should
> be fixed in the next release and so therefore 3 months.
You may want to look at what percentage of those bugs were reported on
one hardware platform by one reporter, and the reporter has since evaporated.
I myself started a thread back on April 26 regarding a wonky PS2->USB adapter.
Within 24 hours I had a bunch of good suggestions for further debugging, none
of which I've had a chance to actually follow up on (Hmm.. Monday is a holiday
but nobody will be in the office, maybe I'll have a chance to get in the 4-5
reboots it will take.. :) So if I had opened a bug, how old is it, and who's fault
is it that it's that old?
> Hitting zero, even for a minute, could be a newsworthy event, as another way
> Linux is better than the others. It also shows leadership to user mode.
Never happen, as at least one of those 2,800 bugs will involve testing a fix on
hardware the reporter no longer has, or the reporter is no longer available, or
similar issues.
You also need to look at the *severity* of the bugs - my USB issue merely
causes me literally 5 second's inconvenience every morning (part of why I
haven't chased it further - it's hard to justify spending 45 minutes fixing a
5-second issue). If the reporter can't be bothered to help, what are we
supposed to do? Then there's the oops and panic reports that should count for
a lot more. How severe are most of those 2,800 bugs?
Probably a lot more productive than "zero bugs" would be "swat the top 10
entries in the kerneloops database", as we know by measurement that they're
both pervasive and high-impact.
Attachment:
pgp00000.pgp
Description: PGP signature