Shipping great software to lots of people is hard. At Mozilla we talk about shipping only “when it’s ready,” and the devotion our community has to Firefox users, and to shipping them a high quality product, is unlike anything I’ve seen elsewhere. We answer to no one but you.
“When it’s ready” doesn’t mean we can take our time, though. Firefox 4 is good for the web, good for our users, and puts the heat on other vendors to up their own game. We need to ship it ASAP – we want release candidates in weeks, not months. And that means a hard look at our blocker list.
Blocker bugs have a rank order. If you can’t have all of them, there are some you’d want more than others, even though every single one of them is a bug we want to fix. That’s healthy. Building software means making those calls. Each bug is evaluated against whether it’s worth holding back the thousands of fixes that have already made it into the Firefox 4 tree. At this point, very few bugs are worth holding back that much awesome.
Hard vs. Soft Blocking1
To that end, then, if you watch bugzilla, you’ve seen blocker bugs sprouting one of two new whiteboard labels:
- [hardblocker] – These bugs prevent us from shipping. We’ll hold the release for the very last one of them. A hard blocker is a failure of a core part of our release criteria, e.g. a crash, a memory leak, a performance hit, a security issue, a UI breakage that can’t be recovered from, an incompatibility we can’t stomach.
- [softblocker] – These bugs are things we want to fix as soon as possible, but can ship with if the hard blockers are done. They can be fixed in maintenance releases if needed, or in Firefox 5 which, remember, is not so very far away. Soft blockers might include visual polish, strange edge cases, optional aspects of new specs, or opportunistic performance wins.
Hard blockers trump everything. That doesn’t mean they are the only things that will get fixed – indeed we hope and expect many of our soft blockers to make it in as well. We didn’t clear their blocking flags, they are still legit work items and have landing pre-approval. Soft blockers are what beltzner calls the “opportunity space” – the work that lifts the quality and delight of the product. But we have to make the hard calls, and soft blockers are second priority to shipping. People paid to work on Firefox will be focusing exclusively on hard blockers, first.
The hard blocker list is currently at 143. When it hits 0, we can ship. Let’s kill it dead.
meandering wildly 
Given that a blocking bug is one preventing release, you’ve just renamed blocking bugs as hard blocking and created a new level of critical bugs called soft blocking.
This probably has stemmed from not enough over sight as to what counts as a blocking bug.
What happened to the wanted+ flag? That sounds like what softblocker is now.
Not sure if it will actually happen in the end, but the current criteria seem to have gone from one extreme to the other.
“a performance hit”
Well, some types of performance hit. Some smaller performance regressions since 3.6 are apparently not hard blockers…
“a UI breakage that can’t be recovered from”
And broken UI that the user can work around is ok. The users will be so impressed with panorama they won’t mind stuff like the browser popping up sync failure messages every couple of minutes and dialogs where the content doesn’t fit…
I think you guys need to be a little careful.
There doesn’t seem to be all that much difference between what previously defined a blocker, and this new [hardblocker] identifier. It also seems to cover a basket of various unrelated bug types.
It seems very optimistic for you to be able to fix 143 “hard” blocking bugs in a little over a month – unless most of them are fixed correctly the first time without regressing, lol.
Performance regressions and the seemingly still present “not responding” states that the javascript engine goes into (doesn’t crash) are all over the Input channel. A typical user isn’t going to tolerate these and will just switch to the C word. 😦
Not that it’s a good suggestion, but can’t FF 4 first be made stable enough, and ONCE that’s done, offer a stable, unstable, and ‘canary’ channels as is done with “that other browser”?
$0.02 from a long-time FF user.
Well, sorry for the digression about the ‘nomenclature’, I see the footnote, but still think your timeframe is rather optimistic.
Sorry but I don’t care if you call it “mario” or “jack”. Guess what, Firefox 4 has got an HUGE mem leak issue which, if not addressed, makes it almost unusable.
On a side note: I understand the (see Chrome) focus on the “masses”, aka today’s Internet “dumb users”, but Firefox success was largely due to its connection with “power users” who act as “evangelists”. I would say Mozilla should pay attention to not lose contact with “power users” while trying to catch the others.
Of course, 2 of the bugs I was worried about being softblockers rather than hardblockers have been fixed in the past day. Hopefully the other one will be too – seems to be getting worked on, despite being a softblocker rather a hardblocker…
What is the difference between a softblocker and a normal bug (where a safe, tested and reviewed patch can get approval)?
Please, tell me you reintroduced a working status bar and I don’t need an extension (!!) for this.
The way URLs are displayed in previous betas, Firefox will become Phisher’s Paradise. It’s just beyond belief how displaying links only in truncated form could get into this thing. What were you guys thinking? Please provide me with your rationale.
Mike, I think they wanted to save real estate for netbook type screens. However I tend to agree – it’s less functional to have the URL up there, and not everyone has a WS monitor…
@Dan: My understanding is that the difference is basically prioritisation. Earlier in the development cycle, the blocker flag is used on everything that is wanted for the release. As the release approaches, they want to identify the blockers that are actually blocking the release. Last time, this was done by changing some of the blockers to “wanted”. This time, they’re using the softblocker/hardblocker thing in the whiteboard. Maybe in a future release they will come up with a better way of identifying enhancements, wanted fixes and actual blockers earlier on. But bugzilla is supposed to be for bug tracking – using it for what is essentially project management is tricky.
@Mike: No, they didn’t. This thread on MozillaZine has links to the Mozilla blogs about the change, as well as 28 pages of argument about it:
http://forums.mozillazine.org/viewtopic.php?f=23&t=1951751
After I started to use Firefox 4 beta 6, the Adobe Flash plugin had start to crash in almost any pages who have Flash. I installed again the player, I updated to beta 8, but still the same problem.
I’m using Mac OS X, 10.6.6.
This can be a problem on my side… or is just because Firefox is still beta ?!
Flash crashes less often for me lately, but I still seem to get “hung” states. So far, have seen fewer hung states with the Beta 9 and/or Minefield, so it seems like some check-ins have progressed on that.
According to Input, many users are still getting hung states, showing either not responding state @ startup, or when loading certain pages. For the first time today in a while I actually have a “long running script” error while using some facebook apps.
@ Mike
If you are using FF4.0b9 the changes to the statusbar can be a wrench…
After a lot of research I recommend these add-ons:
Barlesque and Link Target Display/Locationbar²