Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Mozilla The Internet

Mozilla's 100,000th Bug 304

Posted by timothy from the congratulations-it's-a-bug dept.
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)."
This discussion has been archived. No new comments can be posted.

Mozilla's 100,000th Bug More

Mozilla's 100,000th Bug

Comments Filter:
  • you would imagine most larger projects had this many bugs, if they counted each and every one..
    • Did you read the submission properly? They're mostly duplicates... people submitting bugs that others already have. Bugzilla's email replying facility looks to be a real cool feature! I wonder... does SourceForge's bug tracker have anything close to this?
      • Yep, if you post a bug there's a checkbox to be notified of replies, changes etc. by email.
        • 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?

  • Bugzilla rocks, indeed. (Score:2, Interesting)

    by rekoil ( 168689 )
    My company (a mid-sized national ISP) uses it for internal development/bug tracking. Who else?
    • We use it in our development company. We set up a system for each project we are working on. Clients can review our work as we develop it. They can then submit bugs, suggestions, concerns, and feature requests.

      It has definately cut down on the time we spend on the phone with them, and the clients like the idea that they can go in and see how and when we are addressing each of their submissions.

      In 2 years, will the Mozilla team possibly be remembered as "the guys who wrote bugzilla" instead of "the guys who wrote mozilla"?
      • 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.
        • If you're an admin for an enterprise looking for a high-quality bug tracker, I highly recommend Bugzilla.

          Given today's climate, with businesses not wanting to spend a dime on anything, I might recommend Bugzilla too. If you want to spend money on a decent product, I would recommend Remedy AR. There's not a thing I've seen Bugzilla do that doesn't exist in any other professional tracking db product, and there's several features from even an ancient version of remedy that I liked, like being able to define the UI at the client end, being able to lock down same functionality, the template-driven RemedyWeb, autoalerts configurable per-user, per support group, so on. Bugzilla has the basic function, it just needs a lot of tweaking to not drive the users of it utterly insane if they have to enter about four dozen incidents a day with it.
          • There's not a thing I've seen Bugzilla do that doesn't exist in any other professional tracking db product, and there's several features from even an ancient version of remedy that I liked

            Which goes to show you that YMMV. Personally, I lvoe Bugzilla, use it for personal projects and business development. Its great, I can hack it if I want, and it does the job. I used Remedy in a previous life - what a nightmare. Yes, it had some nice features like the custom UI and stuff, but in teh end it was so sumbersome. They had APIs but we weren't allowed ot use them. We finally got them, they wouldn't compile on HPUX. It was a mess. Remedy was fine if you used the GUI, but try to integrate it with a web front end, some type of script (say a test suite which would open bugs on tets failures, etc) and it was tricky and convoluted.

            Look, nobody is saying Bugzilla is the best bug/trouble ticket system out there. But for the price, its damn good one. I knwo companies out there using Remedy who hardly use any of the advanced features but pay millions for it - in their case Bugzilla could be a real cost saver. Again, every situation is different.

            Me? I was SO glad when I didn't have to use Remedy products anymore - my tic went away!

            • I was SO glad when I didn't have to use Remedy products anymore - my tic went away!

              Like you mentioned, all depends on how it's configured. Using Remedy at one company was evil itself, with the server simply dropping RPC calls at high load causing the clients to time out, and a cluttered UI that couldn't have been designed worse by blind palsied chimpanzees. Then I went to the next company and the interface was simplicity and power itself, it became a joy to use. I found the perl API for Remedy AR was quite functional, but it was unfortunately pretty limited...

              Anyway, Bugzilla is limited by being nothing but a bug tracking system as opposed to a general issue tracking system. It has no concept of asset tracking (useful to know what the configuration of a specific desktop is and how many issues it's generated), SLA's (e.g. having different ticket aging thresholds and actions for different systems), or autoticketing (having a script enter a ticket). Mozilla hasn't needed those features, and a lot of shops don't, but a helpdesk does.
    • We use it as well, with appropriate hacks. It was fairly easy to tie in with our change control system, and the developers can't totally ignore their bugs - email is a bitch at times :)
    • But our clients insist on brain-dead-simple software (oversimplified, actually; they simply refuse to learn or listen to anything technical) to use. We've shelled out big money for Visual Intercept and they're not even totally happy with that.

    • Winamp uses it! (Score:2, Interesting)

      by leibnizme ( 264472 )
      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 [nullsoft.com]
  • ... as the most bugs. What was the quote earler? 250,000 bugs in the latest release of MS's software?

    Now if I could just get the browser to run in a stable, repeatable manner AND not have website CC submision pages crash it out....
  • Lots of bugs == high scalability ;)

    If that's the case imagine how scalable Windows is!

  • You guys may want to wake up. Real-world business applications go far, far beyond 100,000 records. I certainly wouldn't call 100,000 'scalable'. Hell, MS Access can handle 100,000 records just fine. Try 100,000,000. Then we can start talking about scalable.

  • Scalable at 100,000 records? Feh! (Score:4, Funny)

    by kawika ( 87069 ) on Monday September 17, 2001 @08:03AM (#2308689)
    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. ;-)
    • A database I use has a table with 70 million records and another with 20 million.

      I didn't think that Bugzilla was comparing itself to a database. In fact, if you want to make database comparisons, you would need to compare the database that Bugzilla uses against your database.

      I believe the author's point is that Bugzilla has been successfully used through a lifetime of over 100,000 bug / issue reports. This would probaby be considered ample testing to prove that the system was capable of being used in large project environments.

      If you want to make a case against scalability, you will need to point out another bug tracking system that has recently tracked more issues on a single project (or group of related projects). Something other than Microsoft's bug tracking software, please. ;)

      Bugzilla will need to handle those kind of numbers if it is going to be used to track large software projects like Windows XP. ;-)

      On the other hand, maybe if Bugzilla doesn't work so well, it will be incentive to keep the number of bugs at a minimum. Would that be a good method of improving the code quality during the first pass? :-)

      • I believe the author's point is that Bugzilla has been successfully used through a lifetime of over 100,000 bug / issue reports.

        Yes, they must have had the foresightness to allow for such large numbers in the lookup URL.
        Totally useless information...

        If you can't keep the size of the bugreports to, say, 10% of the code size noone could possibly care to fix the code anyway - the only good measure for scalability would be the number of active bugs
    • Bugzilla is tracking 100,000 bugs. However, each bug tracks the following states:
      Product
      Component
      Status
      Resolution
      Assigned_to
      QA Contact
      URL
      Summary
      Status Whiteboard
      Keywords
      Platform
      OS
      Version
      Priority
      Severity
      Unlimited CC's
      Attachments
      Dependencies
      Votes
      Comments
      History

      At a bare minimum, there are at least 20 fields associated with each bug. In general, though, there are several large user comments, attachments containing patches, etc. for each bug. Figure 25 fields as a nice round number. 100,000 Bugzilla bugs >= 2.5 million individual records. Bugzilla.mozilla.org may not be in the 20 or 30 million league, but it's certainly getting there.

      I use Bugzilla on a daily basis, and am also the documentation maintainer for the project. After using it since shortly after it was released, I can say without equivocation that it is more feature-rich, easier to use, and scalable than any other bug-tracking system I've seen. As the first full-featured open-source bug-tracking system released, it has a lot of first-mover support from developers and documentors, and is getting enormously better with each new release.

      Go check it out, pre-populate 20 million bugs in your own database, and see what you think! I think you'll be impressed.

      Sorry if this is too glowing a review; you should expect a biased opinion from those who have used Bugzilla for any length of time : )
      • 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.
      • Just to clarify Matt's comments, please take a look at the schema [trilobyte.net]. Every comment is a long_desc, and is kept in a different record. Also please note the bugs_activity table, this is an audit table and notes every change that a bug goes through. I'm not sure about mozilla, but for our local installation, this table is at least 10x the number of bugs.

        Other tables with a many to one relation to bugs are CC, keywords, votes, and attachments. So Matt's numbers are very reasonable.
    • Bugzilla looks to me like a web front end. It should be able to scale up to a billion bugs. The database behind it is what's important when you start running big queries and reports on it. Took half the damn night to run metrics on the tracking db with a million tickets where I used to do helpdesk... the fact that they didn't index any of the timestamps could have had something to do with it... They preferred to blame it on other factors, so they ended up making searches case-sensitive "for performance reasons" ... i ended up writing my own command-line tools to query the db.

  • Consistancy is the hobgoblin of little minds (Score:3, Troll)

    by rcharbon ( 123915 ) on Monday September 17, 2001 @08:06AM (#2308701) Homepage
    bugzilla.mozilla.org just hit bug 100 000...the number of filed closed bugs cannot be used as criteria of the quality of Mozilla

    Keep this in mind the next time you're dumping on M$ for announcing they've fixed thousands of bugs in a Windows product

    • Now if they only woudn't call it a new version and charge for it....
    • I thought /. was harping on Microsoft for shipping a product with thousands of STILL OPEN bugs. Oh, and the quote is "Foolish consistancy is the hobgoblin of little minds."
      • 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."

    • ofcourse and its good to know that MS ships the product with 65000 bugs that was never attended to !!!! thank you so much for reminding me. And does anybody know if this is true. that the number of bugs in a system increases with the number of lines of code ? 100,000 bugs mean that the code is growing ? or 100,000 bugs mean that attention is paid to the product ? or hopefully it will be fixed ? maybe i should compare the feedback recieved to an MS product, how its handled by techsupport after hours on the hold. to bugzilla ? enlighten me please.
    • Do I contradict myself?
      Very well then I contradict myself,
      I am large, I contain multitudes.

      - Walt Whitman, Song Of Myself
    • There are over 100,000 reports in Bugzilla. The Mozilla community has already resolved about 82,000 of those issues. Not all reports in Bugzilla are filed against the Mozilla application suite. We also use Bugzilla for tracking all kinds of other issues from CVS access to bugs in Bugzilla itself.

      --Asa

  • Lots of bugs == high quality (Score:3, Insightful)

    by HoserHead ( 599 ) on Monday September 17, 2001 @08:07AM (#2308704)
    Unlike what most people think, a high bug count does not equal poor quality. A high bug count is actually a very good indicator of excellent testing, and this testing leads to high quality.

    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!)

    • A high bug count is actually a very good indicator of excellent testing, and this testing leads to high quality.

      I don't think it's so much that a high bug count indicates quality, but the number of those bugs that are actually fixed, of course. Supposedly Win95 shipped with something like 50K unresolved bugs (could be wrong)--in that case, 50K bugs found != quality.
      • "Supposedly Win95 shipped with something like 50K unresolved bugs"

        Which is a meaningless figure since a bug can be anything from the rather important "Win95 fails to boot on Tuesdays" to the less important "Win95 looks horrible in 16 color mode" to the trivial/inane "Win95 lacks a space invaders-type game".

        When your bug system covers everything from show stoppers to feature requests, the bug count becomes fairly meaningless, other than as a source of potential work for the developers.

    • 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.
      • Unfortunately there are very few of these god-like programmers around. Reality dictates that you need a safetynet in the form of a good testing procedure to ensure product quality.

        Bugfree software does not exist so the more bugs you find the better your tests are and since tests are also written & performed by programmers this is also a good indication of programmer quality.

        A test that would result in 0 bugs found is worthless because that just means that the persons performing the tests are clueless. You don't test to prove that your program has no bugs instead you test to find the most visible bugs. In this respect, testing is very similar to research since you generally should try to disprove a hypothesis (and by failing to do so conclude that it must be valid).
  • We also get a lot of duplicates (which dedicated triagers sort out)

    Slashdot's 100,000,000 bug.

  • I don't think this should have been posted... the overwhelming majority of those bugs are duplicates or closed. But all the postings we'll see will either say that:

    Mozzy is buggy as hell since it has 100,000 bugs (duh! read!)

    It can't be scalable if they post a cached link! (not about hardware!)

    100,000 isn't large when considering system architecture (valid)

    So... what's the point?

  • Overlooked fact (Score:4, Insightful)

    by RogrWilco ( 522139 ) on Monday September 17, 2001 @08:23AM (#2308774)
    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!
    • 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?

      Yes, it is. In XP (build 2600 RTM), in the System Control Panel, Advanced tab, there's an Error Reporting button which spawns a dialog with the following options:

      o Disable error reporting
      [ ] But notify me when errors occur

      o Enable error reporting
      [ ] Windows operating system
      [ ] Programs[Choose Programs...]

      [OK][Cancel]

      ( "o" = radio button, "[ ]" = checkbox, "[OK]" = button)
  • I just started using mozilla last week a couple od days before 0.9.4 and propmtly upgraded to 0.9.4 for the stop popups feature.

    Since I have started using it again I remember now how things should work. I use almost not cookies, I have it set to prompt and remeber so it was sorse the first day or so, but has gotten much better.

    Mozilla is a champion for privacy and security, with only one last privacy bugaboo that I feel needs fixing before I switch permematly from pine. That feature is no email should initiate network access ( HTML images, url's, css,... ) becase it;'s an easy way for the marketers to validate the address.

    Cheers to all those that have worked on the project.
  • A common problem with people, as previously said, is that some people take "bugreports" as "bugs" and vice versa.

    A bug report is always a good thing, regardless whether it's a WORKSFORME bug, INVALID or will get FIXED. It means good testing.

    A bug, on the other hand, is something that needs fixing and is never good.

    See the difference? :)

  • On small problem I've had... (Score:3, Insightful)

    by pberry ( 2549 ) <pberry@mac.ELIOTcom minus poet> on Monday September 17, 2001 @08:33AM (#2308825) Homepage

    ...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 ;-)

    • Just try to do your best.
      One of the part of bug triaging is to be sure that the component is the correct one.
    • Have you tried the Bugzilla Helper [mozilla.org]? It really helps newbies write a quality bug report; I highly recommend adapting it to your needs at your site if you wish to run a local Bugzilla where you work. However, it's a bit of a maintenance problem right now; I'd love to see this page automated and cached to allow a user-friendly front-end to bug reporting which tracks the database as it changes, rather than requiring manual updates.
    • I maintain the Bugzilla Helper [mozilla.org], which most people use to file their first few bugs. Any comments on how to make the process easier are welcome. :-)

      Gerv
    • I usually search for similar bugs and then file a bug in the same area. It works pretty well.

      I would like to see dups handled better though. Ideally dups shouldn't be "closed" until the bug that they were marked a dup of is also closed. I have found that an oft duplicated bug isn't found because the title uses slightly different terminology than the search terms. Keeping dups around in the search results would basically allow different descriptions for the same bug and steer people searching for bugs in the right direction.

  • Are there any Bugzilla GUIs? (Score:3, Interesting)

    by magi ( 91730 ) on Monday September 17, 2001 @08:37AM (#2308838) Homepage Journal
    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.
    • Yep, there's one called Mozilla [mozilla.org] ;-)
    • How about writing the bugzilla client in XUL? I personall think that'd be a pretty cool project. Perhaps one day I'll look into it; as I run Buzilla for projects here at our own company. Not likely though; given that I'm prett lazy.

      Justin Buist
    • 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!

  • bugzilla vs. debian bug tracking vs. sourceforge (Score:3, Interesting)

    by Zooko ( 2210 ) on Monday September 17, 2001 @08:56AM (#2308886) Homepage

    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

    • There are not that many around. Before we submitted to Bugzilla, we looked at several systems (late last year), such as Mantis [sourceforge.net], GNATS [redhat.com], Jitterbug [anu.edu.au], and Keystone [whitepj.net]. I have nothing great to say about any of them.

      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 [openoffice.org].

      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 [tigris.org] -- this is a project where the developers actually sat down and designed it beforehand (wowee).

    • 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 [mozilla.org] or here [mozilla.org] for details.

  • The Bugzilla Installer (Score:2, Informative)

    by nn4l ( 73972 )
    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 [softwaretesting.de]

    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.
  • 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.

  • 82,000 of 100,000 Bugzilla reports RESOLVED (Score:3, Informative)

    by asa ( 33102 ) <asa@mozilla.com> on Monday September 17, 2001 @12:35PM (#2309928) Homepage
    from my report to mozillazine.org [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 [mozilla.org] (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?

Slashdot Top Deals

"The pyramid is opening!" "Which one?" "The one with the ever-widening hole in it!" -- The Firesign Theatre

Close