Firefox 3.0 bugs: Mozilla sets the record straight

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.

[chazzzer]

Who's Shipping Anything?

Who's talking about shipping anything? It's a BETA. I've worked in the software industry for over a decade. In the places I've worked, this is the definition of terms:

Alpha: Many things are changing, new features are being added, code tends to be very unstable.

Beta (aka: Code Freeze): No further features can be added, code is becoming more stable, bugs are being fixed.

Release Candidate (aka: Controlled Release): All known bugs are fixed, it is now being tested by a larger group of people to see if previously undiscovered bugs appear.

Shipping (aka: General Availability): All known bugs are fixed, the product is now *shipping* to customers.

Of course Beta 1 will be released with many known bugs...that's how it's supposed to work. Beta 2 will have many less bugs, Beta 3 even less. Eventually they'll get to the Release Candidate 1 phase, then there will be an RC2 as more bugs have been found and fixed, and maybe an RC3 and RC4. The last Release Candidate will eventually become the *shipping* software, and the product will go into General Availability.

If Firefox still has a slew of known bugs when it hits GA, you should write this article again. In the meantime, it's a BETA. Normal people should not use Beta software, because *it's full of bugs!*

[chazzzer]

Hmmm....This Site is Wonky

Strange, I posted this in response to the first article entitled "Firefox 3.0 may ship with a slew of serious bugs intact," but it posted to this follow-up that I hadn't read yet. Well, I guess it applies here too, as you're still talking about *shipping* a buggy product when that product is just hitting Beta 1.

[asadotzler]

Mike Schroepfer

Hey Matt, just noticed a typo on Mike's name (the second Mike). It's spelled Schroepfer. You left off the "o".

- A

[asadotzler]

heh, I mean the "c"

I meant to say you left off the "c". I guess my head's still in the weekend.

- A