80% WONTFIX?

I hate when misinterpretations become seen as fact. Supposedly 80% of Firefox bugs won’t be fixed. That’s said to be a bad thing. Here are some realities:

  • In every release cycle, everyone wants every bug to block a release and therefore everyone is “blocker-happy”, and later in the cycle, all are changed to non-blocker status except the most critical as perceived by developers, drivers, and testers.
  • Every release of Firefox, like every release of every large software project ships with thousands and thousands of documented bugs. The overwhelming majority of which nobody encounters, or are so minor you don’t even notice.
  • This process isn’t new, it’s been happening since the early days of software development.
  • If this process didn’t work like this, there would never be a release of major software products.

A bug is either a defect or an “unintended feature”. Complex products like browsers have thousands. This isn’t a surprise to anyone who works with software on a daily basis. Why? Because every bug you fix, feature you add introduces new code, which potentially causes new bugs in other places. Even if you devote 100% effort to fixing bugs, you’ll likely never get there. That’s the nature of the game. So what makes one bug worthy of blocking? Well generally they must meet some requirements:

  • Must be reproducible and clearly a bug (not a Firefox doesn’t load ActiveX).
  • A fix must be identifiable and achievable.
  • Must be in a more visible location. It’s not effective to allocate large amounts of effort for something so obscure 1 in 10 million people will ever encounter such a testcase.
  • Must be severe in some sense (data loss, security, usability, performance, etc.)
  • Fix must not be beyond risk tolerance threshold.

or, it must be a project requirement, meaning a feature that is deemed necessary to ship the release and worth holding for (artwork for UI for example).

Every project involves deciding what bugs ship, and what holds a release. Every single one. If there’s someone who doesn’t, it means their QA is likely flawed or inadequate. Firefox has the advantage of thousands of nightly testers. This helps quite a bit not only finding bugs, but seeing how prevalent a particular bug is, and what it’s impact is.

One should note that just because something isn’t blocking, that doesn’t mean it won’t get fixed. It simply means the release won’t be held for that bug. Should someone fix it, and it’s approved, it can still potentially make the release. The key is that the fix be low enough risk that the benefits outweigh the risk of potential regressions.

If you’re still shocked by this, let me alert you to something: the product (browser, feed reader, etc.) you are using to read this has thousands of bugs. The OS it runs on, has thousands of bugs. Any alternative you pick will be the same. Pick your poison.

I should note these bugs do not get marked as WONTFIX or INVALID. They remain open. They may be fixed in a subsequent release or they may just become outdated and fixed through some other means (code is depreciated and replaced with something else, feature dropped, revamped).

Tags: , , , , ,

Related Posts

Related Posts


12 Responses to “80% WONTFIX?”

  1. voracity says:

    Wow, that NY Times headline has to be the most stupid, sensationalist, nonsensical and ignorant headline I’ve ever read. (And I’ve read a lot of stupid, sensationalist, nonsensical, ignorant headlines in my time.) Unfortunately, the article itself is no better.

  2. Seconded. When I first hovered over that URL I was expecting Slashdot, not the paper of record. Ho hum.

    – Chris

  3. José Jeria says:

    This is all over the news http://www.macworld.co.uk/digi.....wsID=19679. Also reported by Swedish tech media.

  4. José Jeria says:

    Try the above url without the comma at the end…

  5. Al says:

    You’d think IDG and the NY Times would be more sympathetic, since on this evidence, they only fix 20% of the bugs in their product before shipping…

  6. Let’s also not forget that any new feature is filed as a bug in the database.

  7. […] just got done reading Robert Accettura’s post referring to a New Your Times article about how 80% of Firefox bugs won’t be fixed for […]

  8. Robert says:

    @Shawn Wilsher: good point. And don’t forget those that are duplicates or competing ideas where only 1 of them will ever get resolved.

  9. […] Aclaran sobre “bugs” de Firefox 3.0 Noviembre 20, 2007 Posted by Radamés in Aplicaciones, Firefox, Tecnología. trackback En una entrada anterior reseñé un artículo publicado por el New York Times donde se planteaba que el 80% de los “bugs” o “blockers” que han sido identificados en la versión 3 de Firefox no iban a ser corregidos para no retrasar más su lanzamiento.  Pues representantes de Mozilla han aclarado que los “blockers” identificados, más que errores o defectos, son detalles que los desarrolladores no han podido completar.  Otro problema es que estos desarrolladores han tenido problemas para identificar prioridades en la atención a estos defectos, así que Mozilla ha hecho énfasis en darle prioridad a los más importantes.  Puedes echar un vistazo a la lista de “blockers” para que corrobores las declaraciones del personal de Mozilla y para una explicación detallada del proceso, puedes visitar el blog de Robert Accettura. […]

  10. Steve Skazenski says:

    Wow, Rob, quoted by Ars.

    I’m pretty sure the thing I hate most is people working, managing, talking (or reporting) with/about things they have absolutely no idea about and don’t care to get into any of the specifics of it. Though that’s usually because I’ll be pulled in and have to fix it.

  11. […] excellent article about the recent Firefox 3 “blocking bugs” hubub, and the  resulting response from the Firefox community. I will say that this article and this issue really sums up some of the difficulties of the […]

  12. Robert says:

    Steve Skazenski: The upside of that, is “job security” 😉 .

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

By submitting a comment here you grant this site a perpetual license to reproduce your words and name/web site in attribution.