Couple of articles today reporting that we’re going to ship Firefox 3 with 80% of our current blocker list still remaining to be fixed, which have cause quite the kerfuffle in our little corner of the internet. It appears to be an honest mistake, since a set of meeting notes did include that prediction, along with other elements that mention other approaches to the Firefox end-game, but it’s not our intent to cut Firefox blockers from the fix list against a hard numerical target or fixed deadline. As Matt Asay has noted, we’ve already demonstrated with this product cycle that we don’t roll that way.
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”.
Sometimes, of course, it definitely does mean “we really should not ship without this bug fixed”, which is the most common understanding of “blocker bug”. Over time, our impressions of the severity of something can change, up or down, as usage on the web changes, or features get deferred (meaning that “mandatory” platform changes to support the features are no longer mandatory). Some things that we thought were blockers at one point may well be evaluated not to be later on; we reserve the right to change our minds, as must all learning people and organizations, but we’re not going to do that on a strictly numerical basis, and certainly not on the basis of some system dreamed up by a 16th century doctor.
Of course, we want to get Firefox 3 out to users soon, because there are tens of thousands of improvements there: better support for web standards, speed and memory improvements, great new productivity features, safety and security features, straight-up bug fixes, lots of UI polish, and powerful new APIs for extension developers. But we also need — which trumps the “want” of soon, as you would expect — to make sure that we ship a product that’s good enough for a quarter-billion users (on our current growth curve, we could easily see that many people using Firefox during Firefox 3′s lifetime), that’s worthy of the name Firefox, and that we’re all proud to send into the world. Many of us worked on Netscape 6, so we take this pretty seriously.
Mike Schroepfer, our VP engineering, isn’t dogmatic about many things, which is one of the reasons he’s so good at his job. But he’s pretty damned unequivocal that we’re not going to ship until we’re done, as you can read here and elsewhere:
1) 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.
4) We’ll release betas until we complete our regression work and incorporate feedback from wider-scale testing. Before we release the final beta Performance (specifically Ts, Tp, Tdhtml, Txul, and any other benchmarks we add to the main tinderboxes) will be as good or better than 1.8. We should strive for improved Tp and Tdhtml scores performance v.s. 1.8.
- When will the last Beta ship?
- As soon as it is ready (see #4 above)
There’s nothing new or changed here, other than an unfortunate mixup in some meeting notes and that more people than ever before are watching what we do and how we do it. That reporters are tracking our meeting minutes to track the project indicates that what we’re doing is important to a lot of people, and that makes us more motivated to focus on quality than before, and not at all motivated to push out a release to meet some arbitrary deadline. We’re in this for the long game, and years after the release date is nothing more than nerd trivia, people will remember what Firefox 3 did for them, and how well it worked. It’s going to be awesome, even if you have to wait.
Update: Matt Asay has posted a follow-up article. It’s all good.