Accueil > Bugzilla, Mozilla > Bug stats in the Mozilla world

Bug stats in the Mozilla world

After reading Kairo’s article about bugs triaged in Seamonkey these last few weeks, I wanted to do a quick comparison between main products released by Mozilla: Firefox, Thunderbird, Seamonkey, Camino, Bugzilla, Calendar, and I also included Core and Toolkit. The comparison is interesting, as you can see below (click the image to make it larger… and readable).

As you can see, the two popular products of Mozilla, Firefox and Thunderbird, have many unconfirmed bugs. There are as many unconfirmed bugs as fixed bugs. This surprised me a bit when you know that with such a wide userbase and the QA team, bugs should become confirmed pretty quickly… or quickly be triaged as invalid or wontfix. Maybe are these products so popular that bugs are being filed much faster than they are resolved? I don’t know (someone more involved in these two products would know more).

The other six "products" (products as defined in Bugzilla) have a pretty similar behavior: only a few unconfirmed bugs, and two to three times more fixed bugs than open bugs (bugs marked as ASSIGNED and REOPENED have not been included as they are negligible compared to bugs marked as NEW). Does it mean triaging is more efficient and bugs fixed more quickly in these products, or does it mean these products are less popular, giving more time to developer teams to triage and fix bugs?

Anyway, my goal is not to say who is good and who isn’t in triaging and fixing bugs quickly. I just thought this graph was interesting. You are free to interpret it as you want. ;)

About these ads
Catégories:Bugzilla, Mozilla
  1. 15 mai 2008 à 8:57  

    I used to do browser triage way back when, and at least at that time, the problem was really that nobody was working on triage. Bugs were being filed at a really high rate (at *least* 30 per day) and really nobody was paying attention to the unconfirmed ones.

  2. Alfred Kayser
    15 mai 2008 à 10:08  

    My impression is that bugs categorized to FF and TB are generally raised by end-users, and often quite distant from the actual code-base point of view. There are many, many end-users, with a different view of how the products should work. Besides that the real developers (like me) like to work on the core, toolkit and such.
    To really confirm a bug (not just to confirm the behaviour as reported by the end-user is indeed there, but also to confirm that it is a ´bug´ in the code that needs to be solved, requires people that has intimate knowledge of code, standards and all those complex things.

    Raising a bug is easy. Confirming not. Millions of people raising, and only a few doing triaging…: this all adds up.

    May be we need a way to throttle bugs raised by end-users before real triaging. A sort of initial confirmation (checking for duplicates, non-sense, etc).

  3. Curious
    15 mai 2008 à 10:51  

    How come that the steep drops in Unconfirmed are not accompanied by at least a slight raise in New? What happened to all those Unconfirmed bugs? It just does not seem believable that *all* were invalid. Something must be wrong with these graphs.

  4. 15 mai 2008 à 10:52  

    It’s a cost/benefit thing, I think: what’s the cost/benefit ratio of

    * not triaging a bunch of unconfirmed bugs
    * actively triaging the new unconfirmed bugs
    * not triaging the bugs and occasionally doing a mass-INCOMPLETE resolution

    IMO triaging is more work than it’s worth for the */General components. I tend to triage the new bugs that are filed in the Build-Config and XPCOM components pretty actively, partly because I get bugmail for all of them ;-)

  5. lpsolit
    15 mai 2008 à 11:01  

    @Curious, many of the unconfirmed bugs have been marked as INCOMPLETE when doing a mass-triage of unconfirmed bugs. So the drop in unconfirmed bugs not followed by a jump in NEW bugs is expected.

  6. 16 mai 2008 à 3:38  

    A couple of things:

    The second drop in Firefox UNCO bugs happened last summer when we pushed the community to help lower the number of UNCO bugs. We plan to do something like that again, but it takes man power to coordinate and help new triagers. Most of those bugs were resolved as INCO, INVA, or WFM, while a few were confirmed.

    Secondly, Camino bugs stay relatively low because there aren’t very many filed and our few triagers can keep up with the load. We also, a while ago, implemented a CLOSEME system and started closing out bugs with no feedback. I copied that when we did the UNCO project for Firefox last summer. And… The team is usually pretty quick about making decisions, so the number of NEW bugs hasn’t grown substantially over the years. There’s lots of WONT bugs you’ll find.

    One final note… take a look at the graph for the Tech Evangelism component. A Camino triager has been going through and triaging the UNCO bugs and a few of the NEW ones, iirc.

  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:


Vous commentez à l'aide de votre compte Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s


Recevez les nouvelles publications par mail.