MozillaZine

Mozilla 0.9.6 Released

Tuesday November 20th, 2001

mozilla.org today made available for download binaries of the Mozilla 0.9.6 Milestone. The builds are available on the releases page, or you can get them directly from the ftp site.

New to this milestone are fixes for about 1,600 bugs including support for site icons in both the url bar and tabs (expect IE's favicons to show up in 0.9.7), displaying both Windows Bitmap (.bmp) and Windows Icon (.ico) files inline on all platforms, a new print preview implementation, Page Setup improvements on the Macintosh, Mail message 'labels' (Correction: This feature is not fully complete, only parts of the backed have landed.), and a new select and search context menu item, among others. If you are interested in more information on any of these new features, be sure to check out the release notes.

Also, mozilla.org last week released the source code on which Netscape 6.2 was based.


#123 Re: MZ readers are actually right about bug counts

by strauss

Thursday November 22nd, 2001 12:56 PM

You are replying to this message

> I just did a graph for new/confirmed/assigned bugs vs. fixed bugs, and the fixed bug curve appears to be growing more rapidly than the assigned bugs curve. So what's the problem?

Well, that's not how it works as I understand it from my experiences working with QA as a development engineer. You will note that the <http://bugzilla.mozilla.o…&links=1&banner=1> new, assigned and reopened lines are all increasing. That means new bugs are being filed faster than bugs are being fixed, and that supposedly fixed bugs are being reopened faster than they are being reclosed. It may be that a lot of the new bugs are junk bugs, as has been suggested, but if they haven't actually been reviewed and closed as duplicates, non-bugs, non-reproducible, etc. then there's no real way of knowing if that's true or just wishful thinking. As has been pointed out here several times the lines are not very reliable metrics because the incoming bugs are not getting the attention they need to classify them properly, but in the absence of a better metric we have to rely on the one metric we do have, and that is not an encouraging one.

When a product is on a release track, these lines start to move downwards. That's a generally accepted industry practice. On a large software system it's hard to say exactly what an acceptable bug count is, but it's easy to say what an acceptable bug trend is, and that's downwards.

> during the last year, when the Bugzilla bug count has increased dramatically, Mozilla has finally become a stable, quality browser.

Last time I tried it, it crashed on me and threw away a half hour of work I had put in on a message, and I was then told that there were no useful MTBF ratings for my platform. I haven't tried again, especially since I'm still seeing very mixed reports here. We're still seeing major regressions in both nightlies and milestones, especially in the areas of form elements and text fields. It has gotten better but it's by no means stable. I believe it is true that the relative severity of bugs has declined, but a non-crasher like text fields being too slow to keep up with an average typist is still a big problem.

> Last year, when the bug count was much lower, Mozilla was a less-stable browser that was missing many essential features.

It's the slope of the lines rather than their magnitude that is most important, and the slope is pretty much the same now as it was then. The assigned bug line has flattened significantly, which is good even though there's no progressive flattening, but the new bug line has actually gotten much steeper. It's very important to the product to make whatever structural changes are needed to get those new bugs reviewed -- this should be a top priority of the drivers. Another should be to find out the reasons for the very disturbing reopened line <http://bugzilla.mozilla.o…&links=1&banner=1> .