linux-kernel - Zero bugs (was Re: (Short?) merge window reminder)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 May 2011 10:29:32 -0400
From:	Valdis.Kletnieks@...edu
To:	Keith Curtis <keithcu@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Zero bugs (was Re: (Short?) merge window reminder)

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.

Content of type "application/pgp-signature" skipped