Accueil > Bugzilla, Mozilla > Who is fixing Bugzilla bugs these days? – part2

Who is fixing Bugzilla bugs these days? – part2

Two years and a half ago, I put a graph showing the contributions of main Bugzilla developers. Doing this exercice again on a broader time frame, the results are pretty dramatic (click the image for a larger view):

Top 5 Bugzilla contributors per major release

This table shows you the top 5 contributors per major Bugzilla release, and the third row shows you the percentage of bugs fixed by the top two contributors compared to all bugs fixed for a given release. As you can see, mkanat and I are the two main contributors since Bugzilla 2.20 (released in September 2005), and the ratio of bugs fixed by us two compared to all contributions keeps increasing, reaching 75% (!) for the coming Bugzilla 3.6 release. Knowing that we both have a real life and a day job, I hope you better understand why we cannot fix all bugs and implement all requests for enhancement in a timely manner, and why we have to prioritize what to do next, meaning that some of your requests won’t be addressed in the near future (/me waves some of the Mozilla folks who like to complain rather easily). As always in the open-source world, if you want something quickly, you are welcome to contribute! ;)

About these ads
Catégories:Bugzilla, Mozilla
  1. 11 février 2010 à 12:42  

    Those complaining people are called "customers" :-)

    I think some of the frustration in the Mozilla community is caused, rightly or wrongly, by the perception that the Bugzilla team isn’t listening to their needs, doesn’t implement the features they (as a large software engineering organization and a heavy user of Bugzilla) are looking for, but does implement features that are entirely useless to them. And when they try and improve Bugzilla’s extensibility mechanisms so they can innovate independently, you won’t take their patches.

    There are major things the Mozilla community has been desperate for for years (component watching, branch support) which never seem to arrive. This can be because the Bugzilla team, IMO, regularly lets the best be the enemy of the good. For component watching, Myk produced a patch in bug 76794 in 2004, but was told that it would be preferable to fix a more general bug (278455). Five years later, neither bug is fixed!

    There’s a serious lack of communication here between the Bugzilla team and the rest of the project. We need to fix that, IMO. But it’s not going to get any better if every time a Mozilla person says something, you mentally classify them in the "complainers" bucket.

    Gerv

  2. Frédéric Buclin
    11 février 2010 à 1:20  

    The branch support (bug 55970) and the field watching (bug 278455) are already marked as P1, meaning that they are part of our priorities. Watching components specifically is indeed a subclass of watching any field (bug 76794). The bug was marked as P3; I changed it to P1 right now, to have it in our radar. Anyway, watching the default QA contact is a good workaround for now, so our priority between both would rather be the branch support, IMO. But to implement branch support correctly, we needed some cleanup in the backend, especially in how process_bug.cgi works, which is mostly done now. So it could make it for Bugzilla 3.8.

    Now about wanting too perfect implementations immediately rather than taking workarounds meanwhile, the problem is that it’s hardly manageable, and may trigger serious headaches later when we want to implement it in a clean and extendable way. See how process_bug.cgi worked in the late 2.2x series. It was a *serious* pain to extend, and required a major release or two to come where we are today. We don’t have the manpower you, at MoCo, have with Firefox. We cannot work this way and fix things later.

    But I would be happy to see some more contributions from Mozilla people, not only focusing on their very specific needs, but helping on a more global way, including some re-architecture if needed, to make their specific needs happen faster.

  3. gervmarkham
    15 février 2010 à 1:45  

    It’s great to hear that some of these long-standing issues have been prioritized :-) But have we made sure we have run the designs past the people who are asking for the features? We may think we know what they want, but actually we don’t.

    Here is a good example. I thought I knew what people wanted from "component watching" – getting all bugmail for bugs in particular components. It’s easy, right? But a recent discussion with a Mozilla developer showed me that what he wanted (and I think his use case was reasonably common) was in fact a notification when bugs *entered* or *left* that component. Is this in our component watching design? If not, perhaps we haven’t been listening to our customers enough

    Watching the default QA contact sort of works, but sucks in a number of ways you can discover if you ask a Mozilla developer like bzbarsky.

    I agree it would be better if Mozilla were able to contribute manpower as well as feature suggestions. On the other hand, the ball regarding the current plan for getting more time to work on the Bugzilla core is in mkanat’s court, and has been for a few months now…

    Gerv

  1. No trackbacks yet.

Laisser un commentaire

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

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. 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

Suivre

Recevez les nouvelles publications par mail.