Browser

Firefox 3.0 may ship with serious bugs unfixed

Mozilla will fix just 20 precent of the remaining 700 "blocker" bugs now in Firefox 3.0 before the final version is released next year, the open-source developer's Web site revealed on Wednesday.

Mozilla will fix just 20% of the remaining 700 "blocker" bugs now in Firefox 3.0 before the final version is released next year, the open-source developer's Web site revealed on Wednesday.

Still, as pointed out by Matt Asay in his CNET News Blog, Mozilla has already fixed over 11,000 bugs.

According to the Firefox 3 meeting notes:

We have 700 bugs currently marked as blockers. That's too many. We're asking [requiring] component owners to set priorities on blockers, as a first pass of what bugs should be Beta 2 blockers. You want it to be about 10% of blockers, or what you can get done in four weeks.

The exception is any security-related bug. These should automatically be considered important and fixed.

It is worth noting that Firefox 3.0 is months behind schedule. Mozilla previously stated that the browser was supposed to reach Beta 1 in late July, move into a second beta in September, and achieve its final release by the end of the year.

At the moment, it appears that only Beta 2 will be ready by the December holidays.

Do you agree with Mozilla's method of accelerating the release of Firefox 3?

About

Paul Mah is a writer and blogger who lives in Singapore, where he has worked for a number of years in various capacities within the IT industry. Paul enjoys tinkering with tech gadgets, smartphones, and networking devices.

13 comments
TechExec2
TechExec2

. [b][i]"...We have 700 bugs currently marked as blockers. ... That's too many. We're asking [requiring] component owners to set priorities on blockers, as a first pass of what bugs should be Beta 2 blockers..."[/i][/b] -- Mozilla management My read: This is not wholesale forcing a product out the door with major bugs and problems. This is not like Windows Vista :^0 . They have 700 bugs defined by the developer teams as release "blockers". Project managers are asking the developers to re-evaluate the bugs. Should the release [i]really[/i] be held up due to bug "X" or not? This is a normal part of software project management (at Microsoft too). If project managers don't do these kinds of reassessments, software products will [u]never[/u] get out the door. All software has bugs and all software ships with bugs. The question is: Which bugs? This "bug triage" must be done with great care. Project managers can push too hard and force the shipment before it should go (examples: The space shuttle Challenger disaster; Windows Vista in 2006). Or, they can push too softly and allow the product shipment to be unnecessarily delayed. A huge software product like Firefox has a huge list of features and will always contain some known bugs. But, we must remember that one of the most important features is ... "GA Release". BTW: Irresponsible sensational headlines like "Mozilla Won't Fix 80% of Firefox 3.0's Bugs" in the New York Times written by someone who clearly knows squat about software engineering processes are very un-helpful. That boy needs to be taken out behind the woodshed for a talk.

w2ktechman
w2ktechman

nah, for a beating perhaps :0 Oops, I guess that's what you wer implying anyway....

TechExec2
TechExec2

. A very serious ... never-to-be-forgotten ... bad-behavior-never-to-be-repeated ... talk. I nominate Jaqui to administer the "talk". :^0

jlwallen
jlwallen

Internet Explorer is constantly shipped with loads of bugs. Typically Firefox ships very soundly but sometimes they slip through the cracks. Sounds like this time they are trying to make a schedule instead of releasing the best product they can. Surely they will open their eyes and see the error of those ways. But we can all at least rest assured that even if they do release bugs a'plenty - they will all be squashed shortly after the release. It IS open source after all.

Absolutely
Absolutely

[i]Sounds like this time they are trying to make a schedule instead of releasing the best product they can.[/i] There are legitimate reasons to de-escalate others' issues, in programming as in life. As the bumper sticker says, "lack of planning on your part does not constitute a crisis situation on mine." From the cnet article: [i]As Mozilla pushes to post Beta 1 of Firefox 3.0, it has [b]asked[/b] developers to prioritize already-identified bugs so that the most important can be fixed. But according to notes of yesterday's Firefox 3.0 status meeting, that will leave about eight in 10 bugs untouched.[/i] Schedule is a consideration, and doesn't always imply sacrificing quality. Leaving aside Mozilla's track record, the article simply uses too-dramatic language to describe re-classifying bugs in a [b]Beta[/b] version, which means "still testing," something the author of the New York Times piece did not sufficiently take into account. I hope so anyway; I'm about to download it and see for myself!

frylock
frylock

I don't think that "no worse than IE" is the quality bar Mozilla wants to set for themselves.

w2ktechman
w2ktechman

"The exception are any security-related bug. These should automatically be considered important and fixed." To me I read it as this means that the bugs that may cause the biggest problems will be patched (that they know about), and the others are bugs that should not comprimise the security. With the way SW companies are pushing things out with known security bugs, this is still better. There will always be bugs, and it looks like Mozilla is trying to get to the biggest issues before releasing the Beta 2 version. So I dont see much of an issue with this. Beta testers already know that it will not be perfect, and that known bugs are still there. And they will, I am sure, look for more to add to the list as well.

paulmah
paulmah

Do you agree with Mozilla?s method of accelerating the release of Firefox 3?

frylock
frylock

Yet another reason the software industry is pretty messed up. Reminds me of a major company I worked at where we had bugs marked "show stopper" and "release stopper". Never understood the difference then or now, and iirc we didn't hold up the release for either type of bug. So, what was the point of classifying them as such? If Firefox will ship with unfixed "blocker" bugs, then by definition they are not blockers. (I admit I'm making an assumption, maybe Mozilla means "credibility blockers"). Either Mozilla is cheating by reclassifying bugs for release expediency over quality, or the bugs were mis-classified in the first place. Neither leaves me with much faith in the system. FF 3 == IE 8?

Tony Hopkinson
Tony Hopkinson

Omitted, but from what, I never gave them a spec. A function I don't use, so what, I don't use it Doesn't do what it says on the tin, who wrotye the words on the tin, should it do it any way? As W2K said if it's a security bug, fix it first or provide a safe way of living with it as part of the release. Otherwise prioritise it. Security, Stability, Functional, Cosmetic... One report of a crash, of doubtful value.. There's no point working away at functional if you don't know how many people want the function. Some people describe what I class as a cosmetic bug as serious. There again I'm the developer, so what has it got to do with me?

Editor's Picks