Slashdot Mirror
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)."
My company (a mid-sized national ISP) uses it for internal development/bug tracking. Who else?
Lots of bugs == high scalability ;)
If that's the case imagine how scalable Windows is!
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
I think it was actually only around 65535. More than that, and their excellent bug tracking software overflows...
1) Windows 2000 was not a new creation
2) Many of the bugs are duplicates
3) The fact that they track and repair every bug is a testament to open source
4) Mozilla is an evolving project, which means as more technologies are introduced, more work needs to be done
5) Have you ever written a program the scope of Mozilla without having any bugs on the first go?
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!)
Yep, if you post a bug there's a checkbox to be notified of replies, changes etc. by email.
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!
Each field is a column in a row. Thus 100,000 bugs == 100,000 rows, 100,000 bugs == 100,000 records. 100,000 bugs != 20 million bugs.
I'm sorry you had a bad experience with Linux.
Hammering in code is one of the things in programming that can be a cause of bugs. The more accurate and less sloppy your programmers are, the less bugs WILL BE FOUND during testing. The quality of testing is therefor not determinable from the amount of bugs found. Though: m_iQualityOfProgrammers = CalcProgrammerQuality(iAmountBugsFound, iQualityOfTesting);
So 'the more bugs, the better', please... the best thing you can have after excessive tests is 0 bugs.
Never underestimate the relief of true separation of Religion and State.
...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
More than just a checkbox on the bug, really. You have an entire user preferences dialog for each user where you can indicate your preferences on bugmail for various states of the bug, whether you're on the CC list or you reported it, that kind of thing. It works pretty well.
One unused feature of Bugzilla at bugzilla.mozilla.org is the ability to reply to bugmail and have it tacked into the database. Many others use this feature, however; you can find the Bugzilla email interface and associated documentation in the contrib/ directory when you download the Bugzilla 2.14 tarball.
However, be warned that the email reply feature is not as thoroughly tested as the web interface. This is another reason for it not to be in use at B.M.O. There are currently a couple of notable problems with it:
1. Even if a user account is disabled, they can still add comments to bugs, or create new ones, by sending email to the bugmail reply address.
2. It's case-sensitive on usernames, so if your capitalization isn't correct on your From: header it will refuse to update the bug.
3. You can't currently change parameters of the bug through bugmail (ergo: setting @priority=1 in the mail doesn't work).
It would be great to have a new developer help improve the Bugzilla Mail Interface. Nobody's paid much attention to it for about a year, since Seth Landsman stopped maintaining it. Any takers?
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
Mozilla's Bugzilla is running on hardware designed to cope with the Mozilla development team, not the Mozilla development team + 100,000 Slashdot readers.
Winamp has been using Bugzilla for the last year to assist in developing the new Winamp 3. It's certainly great for developers, provided that they have a dedicated user base that's willing to "weed out" bad or duplicate bugs. It's also great for users who are beta testing - then we can know which bugs they know about, without e-mailing the developers and wasting their time.
While Winamp's Bugzilla doesn't have the same magnitude as Mozilla's, it's still quite valuable.
Winamp Bugzilla
100,000 bugs in total & mostly fixed - not 100,000 open bugs.
Great comment!
: /cvsroot
True that probably half the 100,000 bugs are duplicates. B.M.O. also tracks feature requests.
There are actually a whole suite of webtools for users to check out, including Bonsai, Tinderbox/Tinderbox2, a rip-off of an old version of LXR, automated build scripts, and some miscellaneous stat-tracking stuff. However, behind Mozilla, Bugzilla is far and away the most popular product at mozilla.org. We very recently changed it from being part of the Webtools product to its own product entirely, and since the 2.12 release its popularity has just exploded.
I'd love more people to start using the other webtools as well! Where I work, we're using Tinderbox2 and Bonsai. Tinderbox2 is email-based automated build tracking which integrates with CVS, while Bonsai is a MySQL-based CVS query front-end. Bonsai is quite similar to CVSweb, but offers powerful query features and some automated tracking (it doesn't handle spaces,though -- if you try it, you've been warned!). If you have a need for powerful CVS queries and automated build tracking, give them a shot.
Tinderbox2 and Bonsai are available via CVS, like the very latest Bugzilla. To check it out on a UNIX system:
$ export CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org
$ cvs login
password: (anything works here)
$ cvs checkout mozilla/webtools
or for just CVS Bugzilla:
$ cvs checkout mozilla/webtools/bugzilla
Have fun!
Matthew P. Barnson
I learn what I think when I read what I write
I said it before and I'll say it again. Win2k shipped with n thousand bugs. Mozilla has 100,000 bugs fixed. Can you see the difference?
Why can't I moderate something "Wrong" or at least "Grossly Misinformed"?
Again, Windows 2K SHIPPED with that many bugs. The 100,000 count is the total number of bugs SUBMITTED. It's more like the difference between "There are 65,000 stories on Slashdot's frontpage", and "100,000 stories have been submitted to /., most have either been rejected, or posted on the page. There are a few in the submission bin." Windows 2K is like the first one, Mozilla is like the second one.
--You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
Mozilla DOES NOT HAVE 100,000 BUGS!
Thoughout the whole development process, 100,00 bugs have passed through the Mozilla code, this includes integration of new features where things aren't finished and don't work right, and well, everything else that gets put into bugzilla.
W2k was released with 20+k bugs in the finished product. But, who knows what those bugs are anyway, I've see plenty, but that large number could include things that most wouldn't consider to be real bugs, so, whatever...
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Win2K shipped with all those zillions bugs unfixed.
Only a fraction of the 100000 Mozilla bugs are "open issues". The rest are fixed bugs, duplicates, invalid bug reports, as of yet unfulfilled feature requests and, in some cases, jokes. =)
(It's good to see that "the lack of [some cool feature] bugs me" is considered a program bug, not an user's fault =)
> but then my free product isn't being very free, is it.
:-) It's your loss.
Free software != Someone else does all the work for you. It's free (libre).
> Open Source is terrible at getting the last mile done.
If your company doesn't use Bugzilla because it judges on appearances rather than function, do you think we give a monkey's?
Gerv
Bugzilla is somewhat difficult to install. I have written a few shell scripts that help install Bugzilla on any UNIX system.
This article has detailed instructions and all required source code: The Bugzilla Installer
The Bugzilla Installer will unpack, compile and install Bugzilla and all required components on a UNIX system. Administrator rights are not required; you can install everything in an arbitrary location. It has been tested on different Sun Solaris and Linux installations.
100,000 bugs doesn't really constitute a *large* database
Have you looked at the schema? A bug is a very complex thing = it's not just a row in a table. Add in 50,000 file attachments as well.
Gerv
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).
And for something constructive for a change, I'll tell you how you can contribute to Bugzilla.
The project's home page is "http://www.mozilla.org/projects/bugzilla/". Most of the developers hang out on the IRC channel.
If you already have Tinderbox running, I would see no reason to upgrade to Tinderbox2 (and neither does the Mozilla team at the moment). The biggest deal is that T2 is relatively easy to customize for third-party developers outside of mozilla.org. Eventually, I think Tinderbox2 development will surpass the original Tinderbox. Tinderbox(1) has a whole lot of mozilla-specific stuff in the way it works. T2 is a whole lot more generic, and seems quite expandable. I encourage you to give it a shot, but if yours isn't broke...
Matthew P. Barnson
I learn what I think when I read what I write
Here is a chance for Bugzilla to take a quantum step beyond other bug tracking software. If any of the bugzilla maintainers are reading this please consider adding SOAP API to bugzilla as a neutral and independant way to manipulate bugzilla instalations. This way you can design any GUI you want while talking to the same server software.
It seems that usually the next step after designing a robust web server application platform is to somehow externalize functionality so that things that aren't web browsers can use it as well. Go for it Bugzilla!
You *can* do this in Bugzilla, but you need to enable the contributed Bugzilla Mail Interface in contrib/. That contributed package is in some need of maintenance, however.
Check here or here for details.
Matthew P. Barnson
I learn what I think when I read what I write
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.)
Just because Bugzilla works well for a large project like Mozilla with many developers and many reported bugs does not necessarily qualify it for "scalable".
It only proves its utility for a particular large project.
My group has been looking to find a good bug management system that is truly scalable. By that I mean one that works as easily for a small project with a few developers as for a very large project.
The differences are that a very large project might be able to afford to have one person whose full time activity is managing some piece of complex bug tracking or issue management software, be it some commercial offering or be it Bugzilla.
I am so tired of products being sold and bought purely on the long list of "features" without any regard for usability. Can anyone produce a product with an appreciation that the casual user, reporting a bug once for some piece of software, does not want to be overburdened in having to spend hours or days climbing the learning curve for Yet Another Software Application.
Scalability to the low end as well as the high end wins marks in my book.
While I've been skeptical of Bugzilla for being no more than a Pile 'O Perl Scripts, I must admit it is doing well for Mozilla, having used it once to submit a bug and gotten subsequent emails indicating the progress being made on the bug (even if the progress was a message to the effect that the bug was morally equivalent to something else and that I was too stupid to realize it - that's OK).
But has Bugzilla been used successfully for smaller projects? And for users/bug reporters that are not necessarily the same as developers?
"Provided by the management for your protection."
Not to mention that that's one version of Windows versus the lifetime of mozilla. during which bugs were reported based on constant trial and error of the software in it's current unfinished state. And if you understoof the workings of bugzilla at all you'd realize that the word bug in this case also includes duplicates, RFE's, feature requests, stuff that isn't a bug in the strictest sense.
I'm the big fish in the big pond bitch.
#!/usr/bin/perl
The above script has NO bugs. Therefore any program does not necessaruly have at least one bug. QED.
I'm the big fish in the big pond bitch.
One thing's for sure, you couldn't store it with a 32-bit integer!
Dyolf Knip
I thought /. was harping on Microsoft for shipping a product with thousands of STILL OPEN bugs.
Yep.
But given that the count includes new features, it would be as valid to proclaim that Mozilla had 100,000 new features, then start deducting the bugs.
Besides: A documeted bug IS a "feature". Right? B-)
Oh, and the quote is "Foolish consistancy is the hobgoblin of little minds."
A non-rational quote used (from the first time it was uttered) to avoid valid arguments in debate by belittling those who make them.
I prefer a slight rearrangement: "Inconsistency is the mind of a foolish little hobgoblin."
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way