Mozilla 0.9.6 Released

Tuesday November 20th, 2001 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, last week released the source code on which Netscape 6.2 was based.

#120 Re: Re: Re: Re: Re: Re: Re: Re: Re: What happened

by bcwright <>

Thursday November 22nd, 2001 11:20 AM

You are replying to this message

>To me this seems to indicate that the bug database is >not a very useful tool for understanding progress >toward the goal, which is a very dangerous situation -- >it's like flying with no instruments.


>One is bugs targeted at a specific milestone. One expects >some of these to slip, but the slip numbers are large, in >the three figures per build.

If you look at the way bugs seem to get targetted, the tendency seems to be to just make a wild guess that maybe we can fix this by such-and-such a date. There is little effort to spread out or prioritize the bugs over several milestones; they tend to get lumped into the next available milestone. This is oversimplifying of course, but that's the tendency. When the inevitable happens and not all of them get fixed for that milestone, they just get moved to the next one, and so forth. Naturally this implies that the number of bugs targetted for a specific milestone has little meaning - it's more of "a wing and a prayer." Now how important this is depends a lot on what kind of bugs these are and what the endpoint target is (both in time and in features and stability), and also whether the bugs that are actually fixed fit into the range required to meet that target. A milestone isn't the same as a release, but to the extent that the bugs that get pushed back are serious defects (as opposed to minor defects or new features), it can make it more difficult to control the project. The amount of effort to correct a defect is often difficult to predict, since it will involve tracking down what's causing the problem and then devising a solution. Often the time is heavily weighted towards tracking it down. Adding features is much easier to predict, you usually don't have that big initial cost and can go directly to designing the feature. If you have too many real defects you'll lose control of your schedule. Not that any of this should be news to you but it might be to anyone who hasn't been involved with it before.

>Another is the bounceback rate, that is, the reopened >bug line, a standard indicator of overall system stability.

And this is the most worrying indicator of all, but you never see it mentioned on Mozillaquest. Instead he is almost totally focussed on the overall bug counts and the number of bugs targetted for each milestone, which aren't very useful figures given the way that uses bugzilla.