Mozilla's 100,000th Bug
benb writes: "bugzilla.mozilla.org just hit bug 100,000 (cached). This proves its scalability. BugZilla is used to track work on Mozilla. Every change has to have a bug. This includes new features and bugs found by developers/testers during development (bugs that never reached users). We also get a lot of duplicates (which dedicated triagers sort out). So, the number of filed closed bugs cannot be used as criteria of the quality of Mozilla. During usage, BugZilla evolved to a very comfortable web platform for filing/tracking bugs, one that has only very few competition (of which I know). Examples are the emailing and dependency systems. In fact, BugZilla is probably the most important communication medium used in the Mozilla project (apart from the source code itself)."
I think it was actually only around 65535. More than that, and their excellent bug tracking software overflows...
Don't get me wrong, I'm glad that someone has tried to attack the bug-tracking problem. But 100K records isn't even a decent test case for most big database projects. A database I use has a table with 70 million records and another with 20 million. Bugzilla will need to handle those kind of numbers if it is going to be used to track large software projects like Windows XP. ;-)
Keep this in mind the next time you're dumping on M$ for announcing they've fixed thousands of bugs in a Windows product
Mozilla is a very high-profile application, and is also very complex. A lot of people report bugs in it, ranging from showstopping to very trivial. I'm personally very encouraged that Mozilla has such good testing, because it directly translates into a better product.
Bottom line is: the more bugs, the better. (This is something a lot of people don't seem to recognise, particularly with Free Software development. When that user reports a bug you don't like, thank them instead of closing it without fixing it! They're contributing to the quality of your software!)
I think it was actually only around 65535. More than that, and their excellent bug tracking software overflows...
Good thing they at least don't sign their shorts or else we would be seeing only 32767.
Also, it does not overflow for Microsoft; they just think they have eliminated a lot of bugs when the bits cycle around.
Mozilla has yet to reach 1.0, which they stated would be the equivalent of a production release. For al the linux bashers, that's 100,000 bugs which never made it to the release product.
Similarly, why did MS build bug reporting tools into XP and IE 6? To build a better product. Too bad that they are all basically new versions. Anyone know if this is in the final release?
Windows XP = Windows 95 v5.0
95->98->98se->me->XP!
I think it's very possible that mozilla.org may become better known for Bugzilla than Mozilla : ) Bugzilla is already the premier open-source bug-tracking system; I consider it a really good point in the favor of any company if they are using it.
However, I must caution that it's still a real pain to install on Microsoft Windows, and requires non-trivial UNIX knowledge to make work on a UNIX platform. Also, it's heavily geared towards Apache web server, since that's what B.M.O. uses and most of those admins running Bugzilla use it. AFAIK it still works fine on iPlanet and IIS, but you need to implement your own security to protect certain critical files from remote inspection. There's a file we use called "localconfig" which contains your database password; that file must not be readable by web users!
If you're an admin for an enterprise looking for a high-quality bug tracker, I highly recommend Bugzilla. If all you're looking to do is track bugs on a very small product, or if you're not an experienced admin on your platform of choice for Bugzilla, a mailing list is probably much more the thing for you. I love Bugzilla, but like most other enterprise-class software, it can be difficult to get up and configured correctly, particularly if you don't already have the necessary prerequisite packages already installed.
Matthew P. Barnson
I learn what I think when I read what I write
...is trying to figure out where a bug should be filed. The bug page is daunting, especially if you aren't familiar with modules and how they are broken down.
I only mention this because I run the nightly builds just about everyday and they ask us to help file bug reports.
This problem may be a combintation of bugzilla user interface and the complexity of the mozilla project though, and not just one or the other...
But if the developers like it, that is probably more important ;-)
-- Are you an EFF member yet?
I have always found the web interface awfully awkward to use. Are there any frontend client applications for it?
While web interfaces are easy to make and maintain, client apps are usually much more user friendly. Most importantly, they make it possible to add features on the client side without need to modify the web service. That's why we have mail and news clients - web email systems generally suck and are difficult to improve without the involvement of the provider of the server software.
I would imagine that a GUI would be especially useful for the developers, as it could update the bug lists without having to refresh web pages, etc. It could also hold a local copy of the database, for doing searches, etc. Well, on small databases at least.
The GUI could also be integrated to the apps. For example, KDE already has some nice support for sending bug reports from applications, but it could be improved, especially for searching existing bugs. Eliminating the use of web browser entirely would be a great improvement for making bug reports.
It is, unfortunately, true that Bugzilla is fairly easily swamped by massive traffic. We encourage the use of mod_throttle on Apache for just this reason. Often, web spiders attempt to index publicly-available Bugzilla sites, and that can basically amount to a denial-of-service attack.
I think you'll find this is true with most heavily dynamic, database-driven web sites. I'd ultimately love to get better scalability than Slashdot out of Bugzilla, but in the near-term we're trying to avoid dependencies on mod_perl and certain other areas of performance enhancement because they cause dependencies on certain types of web servers.
There is some heavy discussion going on amongst the Bugzilla developers about using some kind of caching method to prevent slashdotting of Bugzilla in the future, but for now it's not there. Contributions welcome!
Matthew P. Barnson
I learn what I think when I read what I write
Is bugzilla better than debian bug tracking? Which is the best bug tracking system?
Personally, I refuse to use SourceForge's bug tracking system because it requires that I fiddle with a mouse and click on little HTML widgets and then wait for a few seconds while the form is submitted to see if it worked. I have better things to do with my time than waste it trying to use HTML and HTTP as a user interface.
I really love debian's bug tracking system, and the `reportbug' package, which allows me to do all my bug reporting with good old e-mail, from the command line, as God intended.
Regards,
Zooko
They all lack many essential features. They all have web-based GUIs that are tighly coupled with the back-end logic; that is, they have no back ends. Thus the default GUI is the only GUI you can ever realistically put on top of it. A lot of people are missing out on the MVC model these days. What you need is a programmable back end accessible through a cross-platform API (based on CORBA, SOAP, XML-RPC, UNO, anything that strikes your fancy). Then you can leverage the back-end support for clients. One can be a powerful reporting tool with graphing capabilities. Another one can be a wxWindows-based portable GUI for modern desktops. Another one can be a common-denominator HTML-based GUI for browsers. Etc.
Current GUIs are all crude and cluttered and obviously designed by programmers with no interface design background (and by that I don't mean graphical design, but functional design). Many are ad-hoc systems thrown together using PHP. Presumably the poor devils think that by slapping it on SourceForge or Freshmeat it will magically bloom into a usable product. Nuh-uh.
Another common problem with these systems is that they're fundamentally bug-tracking systems. When you get to a certain point in development, you realize that a better all-embracing concept is the idea of issues -- a generalization of problems that aren't specifically related to code. There is a popular fork of Bugzilla, for example, called IssueZilla.
The only system that was mildly interesting was Keystone, which provides some interesting form-based extensibility -- basically, if I remember correctly, the schema is malleable, so you can add stuff like time estimation numbers, completion progress, or other metadata that would be useful in your project. Also Keystone supports the notion of subtasks: any bug "slip" can have another slip as its parent. This is more elegant than Bugzilla's dependency system. Unfortunately, Keystone sports a GUI from hell. (Applying CSS to it might sound fun, but it isn't; their HTML isn't very CSS-friendly, so to do anything radical you have to delve into their HTML generation code).
We currently use Bugzilla. It's currently the best system out there, but that doesn't say much. We are pretty excited about Scarab -- this is a project where the developers actually sat down and designed it beforehand (wowee).
from my report to mozillazine.org:
The recent posting to slashdot about Bugzilla's 100,000th report begs the question, "what other numbers can you give me?" Here are a few of the numbers I pulled out of the database last night. These numbers are all a little rough but should help make the picture a little more clear. About 18.7% of the reports in Bugzilla are still open (UNCONFIRMED, NEW, ASSIGNED, and REOPENED) issues. About 32.8% of the reports have the FIXED Resolution. About 45.4% of the reports in the system are WORKSFORME, INVALID or DUPLICATE. To break that last number down a little more, 26.3% of the database is Resolved as DUPLICATE, 12% WORKSFORME and 7.5% INVALID. About 5.5% of reports in the system are reported against something other than the Mozilla application suite.
So just in case anyone missed it in the fine print, Bugzilla has 100,000+ reports but the Mozilla community has already resolved about 82,000 of those reports. It's probably also useful to know that there are over 32,000 Buzilla user accounts. You can find more on the Mozilla QA and testing community at my O'Reilly OSS Convention presentation (you'll want to use a browser that supports the latest web standards.)