Firefox 4, A Huge Pile of Bugs

surveyork writes "Firefox 4.0 beta 9 (AKA 'a huge pile of awesome') was released on January 14, 2011. Firefox 4's release schedule includes a beta 10 and a release candidate before the final launch in late February. However, one wonders if this schedule won't slip again, since there are still more than 100 'hardblocker' bugs, more than 60 bugs affecting Panorama alone and 10 bugs affecting the just-introduced Tabs-on-Titlebar. Some long-standing bugs won't be fixed in time for Firefox 4 final either (example, example). Many startup bugs are currently pending, although Firefox 4 starts much faster than Firefox 3.6. As a side note, it's unlikely that Firefox 4 final will pass the Acid3 test, despite this being a very popular demand amongst Firefox enthusiasts. Perhaps we'll have to wait until Firefox 4.1 to have this 'huge pile of bugs' (mostly) fixed."

Comments

Re:Rate of incoming new bugs v.s. outgoing fixed b

[tjwhaynes]

You clearly have never worked on a large software product.

During development of a product, you will see new bug rates go much higher than fixed bug rates. This imbalance will continue until you stop adding new features and focus purely on stabilization and product delivery. Firefox 4.0 beta 9 is still landing features (some of which have been baking for a long time in separate branches) so their bug rates look pretty sane to me. All products ship with known bugs - you just try to trim the list down to things that users are highly unlikely to see.

For web browsers, crash bugs are the most dangerous. They may represent routes through the code where bad pointers are being consumed and these can potentially lead to remote exploits. All reproducible crash bugs should be fixed as soon as possible.

Having browsed through the outstanding bug list for Firefox 4.0 and looked at the planned schedule (late February release), it looks reasonable. If some of the new features lead to a burst of new defects, I suspect that date will move out or features will get blacklists (like the WebGL/ Hardware acceleration blacklists for Linux)