CNET también está disponible en español.

Ir a español

Don't show this again


Firefox 3.0 bugs: Mozilla sets the record straight

80% of its bugs unresolved? The story isn't so simple.

Whenever I'm writing something here and my subconscious whispers, "You're probably wrong," I should learn to stop and ask. Alas, I'm a blogger with a day job, so I usually hit "Publish" and wait for someone on the other side of the issue to set me straight.

Such is the case today with Mozilla's Firefox 3.0 release, which I (and a wide range of others) reported would be shipping with 80% of its (remaining) blocker bugs/issues still unresolved. The truth is not so simple, as it turns out.

Mike Shaver of Mozilla clarifies "blocker bugs" and puts things in perspective:

At some point, of course, the number of "bugs we'll ship with" will hit 100%, unless we manage to produce the first piece of bug free software I?ve ever worked with, but even with such numerical truisms aside, the picture here isn?t as simple as it seems.

"Bug" in our world - as with every software shop I?ve ever worked, to be honest - includes desired feature improvements, optimizations, basically everything in the gap between "how the software is" and "how someone would like the software to be". Because of history and some tool limitations, and because we now have a larger set of people triaging blocker nominations than we ever have before, the "blocking" flag doesn't always strictly mean "we would not ship Firefox 3 if this specific bug isn't fixed". It can also mean "we should look at this in more detail before we ship" or "we'd like to focus developers on this set of bugs" or "don't forget to do something (release note, document workaround, reach out to site authors, etc.) here before we ship".

Of course, sometimes a "blocker bug" really is just that: a bug that makes the system unusable or has the potential to render it such. Mozilla has no intention to ship with such bugs in the product, as its VP of Engineering, Mike Shroepfer, writes:

We are driven by quality, not time. We want to Firefox 3 to be something that we are all proud of. This means features that delight users and the same or higher quality than previous releases. "Quality" includes performance (Tp/Ts/TDHTML/etc), footprint, web compatibility, regressions, and general fit and finish. Having said that, we want to move the web forward and are in a competitive market. So we should converge on a release as fast as possible.

That's what I expect of Mozilla. I'm glad to be very wrong on this one. So is my browser.