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.
#120 Re: Re: Re: Re: Re: Re: Re: Re: Re: What happened
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 mozilla.org uses bugzilla.