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.


#169 Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: What h

by asa <asa@mozilla.org>

Friday November 23rd, 2001 3:57 PM

You are replying to this message

" After all, the entries targetted for 1.0 (which is supposed to be an actual _release_) matter a lot more than those targetted to just a single _milestone_. "

The number of bugs targetted at 1.0 is not a realistic measure of the bugs that would prevent a 1.0 from happening but this number should continue to go down as people evaluate them against the kinds of fixes that a long lived 1.0 branch needs. 1.0 is the point at which mozilla says "the code should be good enough for you to use." Things that matter for 1.0 are frozen interfaces, stability (the 'doesn't crash' kind), performance, footprint, etc. (see the manifesto <http://www.mozilla.org/roadmap/mozilla-1.0.html> for more info).

I share your concern that the 1.0 targeted bugs are a lot of 'nice to have' or enhancement bugs and that this can be distracting, misleading and even dangerous. We're working to get that list triaged down to something more meaningful (see the recent drop of about 25%).

I also agree with your suggestion that we need more focus on fixing core problems and less on adding features. There are lots of things that can and should wait till 1.1 or later. This will have to happen if we want to fix the api, stability, performance and footprint caatagories of bugs I mentioned above.

Bugzilla reports are one method for measuring areas of quality in Mozilla. There are lots of other measures. We test performance, stability, functionality, footprint, etc. You could say that our page layout performance is getting worse because there are more open bugs today reported against performance than there were a year ago but that measure proves to be wrong when you actually look at the page load metrics at <119/3BFB7296.41831EB9@netscape.com>" rel="nofollow"><news://news.mozilla.org:1…<296.41831EB9@netscape.com>> . You could say that our stability (the 'doesn't crash' kind) has gone downhill because there are more open bugs reported against stability (keyword or summary containing 'crash') than there were a year ago but that also proves to be wrong when you look at our MTBF stats over time at <http://ftp.mozilla.org/pub/data/crash-data/> You could say that our interface stability story is worse today than it was a year ago because there are more bugzilla reports about freezing interfaces than 1 year ago but the forzen and under review APIs at <http://www.mozilla.org/pr…embedding/PublicAPIs.html> again demonstrates that a growing number of bugs does not mean we're losing ground. In fact, in many cases, the growing number of bugs has everything to do with gaining ground on an issue. As we focus on something like page load performance and work to drive that metric we test more thouroughly or specifically and report more bugs against code which could impact that metric. For example, if we do profiling on page load and identify 100 pieces of code that could be improved getting us 1% perf increase each and so we file 100 bugs and target them at 1.0 (because page load perf is important to 1.0) and then we only get 50 of them fixed by 1.0 increasing our performance significantly, I don't consider that hypothetical a failure. By the quality tracking discussions I'm reading at mozillazine we should just as well not do the profiling, not find the 100 places we could improve and not work to fix as many of them as possible. It's being suggested here that the only measure we have is the total bug reports and if that number goes up faster than than the fixing then we're getting worse. I dispute that kind of arguement. There are too many places where we have more bugs reported about a catagory of problem today than we did a year ago but that area is significantly better than it was a year ago.

--Asa