http://ostatic.com/blog/fixing-the-perception-of-bugs

http://lists.gnu.org/archive/html/emacs-devel/2010-06/msg01025.html

Stephen made that post in a thread about the number of open bugs in the Emacs bug tracker. Money quote: “Sure, you can and should try to reduce the number of open bugs in Emacs, but I think you’re going to end up needing to accept 4-figure counts just like everybody else.”

Triage is the normal state of affairs, I agree. Especially in a codebase adding code.

There is a curve that levels off where adding more users doesn’t appreciably increase the surface area used. If I selected 1,000 random people around the world and looked at all their bugs, it would cover the vast majority of the bugs in the Ubuntu bug database.

In any case, Ubuntu is filled with bad bugs, so any theoretical analysis doesn’t matter. They might not be able to hit zero bugs, but they can make up many other good goals. I was suggesting zero bugs not also linked up to the upstream buglist. There are many interesting goals that Ubuntu could set over time.

If I could change one thing about the free software culture, it would be to push more for them to think about crashes the way airplanes designers do. When you have 100 million lines of code, you need to push for high quality or it will fall over constantly.

I’m not saying people shouldn’t fix bugs. Of course they should. But we need to understand that triage is the natural state of affairs.

Driving a widely-used system’s bug list to zero? Good luck with that . I don’t think it’s going to happen.

You wrote: “The number of bugs is not correlated to the number of users because fixing bugs changes the number of bugs.”

They will always come in faster than you can fix them, because what causes them to come in is people encountering them. The more users you have, the more “surface area” the software is exposed to, so the more flaws will be reported. It’s not necessarily that more flaws will be found, it’s that more will be reported, because a growing user base increases the probability that at least one of the users who encounters a particular bug will report it — because a larger number of users total are encountering that bug now.

If Postfix decides not to keep a permanent, easily findable record of bug reports that they’re not going to fix right away, that’s fine, but then they’re practicing the “lower the number of bug reports by discouraging filings” method. I don’t know that that leads to better or worse software, but it certainly makes it harder for conscientious reporters to find duplicates.

BTW, I have found that Akismet does a great job dealing with spam and that captchas are unnecessary.

I think if you look at other types of engineering: airplanes, buildings, etc. they might agree that there is no one perfect way to design something, but that if it did crash it would be a bad thing. If you look at many of Ubuntu’s bugs in launchpad, at least 50% look bad. And lots of people are complaining about Ubuntu’s bugginess. I believe working aggressively on the bug list can help improve the perception and the problem.

And there is a problem about letting bugs linger. The fact that the iPod w/ iTunes doesn’t work on Linux is a barrier that affects 200M people and is still broken 8 years out. As long as a community is churning through its bugs, then it is moving the codebase forward in all important directions. Now in Ubuntu’s case, each bug needs to be verified, and then shepherded into the upstream codebase. Perhaps focusing on the number of unverified bugs should be Ubuntu’s goal. Once you’ve handed it off to the proper upstream developer and answered his questions, then Ubuntu has completed an important job. It would be interesting to try to get that number to zero as a start.

Recent; trivial patch (according to the submitter); not applied. Again, I don’t know whether what the submitter says is accurate, or whether this is a bug at all. But it is being tracked in a bug tracker — at Launchpad.

So in a sense, there is no such thing as a project without a bug tracker anymore, hmm. The project may or may not have its own tracker, and the developers may or may not think they need it, but someone somewhere is tracking bugs anyway, and one of those places will probably become the default “list of record” in the absence of anything more compelling.

That is really interesting. I’d love to know there’s a counterexample out there, but is it a definitional issue? If one defines “bug” narrowly, it might be possible to fix every bug (though I confess skepticism even then), but sometimes that’s just a way of saying “we don’t track enhancements or feature requests as bugs”. Also, if you don’t have a bug tracker, maybe that just discourages some people from filing bug reports. I.e., how do you even know what the set of “known bugs” is if you don’t have a tracker? Is the report rate just so slow that it’s possible to keep track manually on the mailing list?

By the way, does this mean all the upstream bugs in the list at https://edge.launchpad.net/ubuntu/+source/postfix/+bugs are fixed already? Real question, not rhetorical; I haven’t looked at the list in depth.

Anyway, thanks for the observation. It is certainly a different model; as you can tell, I’m not quite willing to believe the claim that a non-trivial project leaves no known bugs unfixed, but I wouldn’t reject it out of hand either. If someone who reads these comments is a Postfix user, let us know .