Full Article Attached 0.9.2 Branch and Beyond

Sunday June 24th, 2001

Chris Blizzard has posted an update on current tree management plans for the 0.9.2 branch and the 0.9.3 trunk. The plan calls for to drop the requirement of approval for check ins to the trunk, while continuing it till 0.9.2 is finished on the branch. Chris felt that using 0.9.2 as a stability milestone was a success, partly thanks to the drivers requirement, but mostly due to better self policing by those who were checking in.

When 0.9.2 is completed on the branch, Netscape will take over control of it, and continue checking into it for an upcoming release. The build Netscape chooses to release will also be released by as

Finally, Chris stressed the importance of continued self policing, to keep up the high level of stability that the past 2 weeks have achieved. To read his entire post, click the Full Article link.

#34 The point is the goals changed!!

by bcwright <>

Tuesday June 26th, 2001 1:52 PM

You are replying to this message

The point is that the goals changed. If you want to discuss this intelligently it would be in your best interest to read some of the references at <> <> and also <> - it doesn't sound like you have, so you're shooting from the hip so to speak.

The 0.9.2 milestone was changed from being primarily a "development" milestone to being a "stability" milestone. If you don't understand what this kind of change means in software development parlance, here's a summary:

In a development milestone, the developers are trying to add features and fix problems whose solutions might be more risky. For example, a "bug" might be that a particular part of the program is slow or inefficient but works correctly in the sense that you get the right answer. So you have a higher chance of regressions, that is, introducing a lot of NEW bugs since you're likely to be adding a lot of new code.

In a "stability" milestone, the concentration is getting the product to work reliably - even if there may be some inefficiencies or cosmetic problems or a few missing features. Bug fixes that involve a lot of risk of introducing new bugs will be discouraged unless the bug that's being fixed is fairly serious or the feature being added is considered essential.

Note that all bugs are NOT created equal, and shouldn't be treated as being of equal importance. Talking about raw bug counts does exactly that.

If you really want to discuss software development issues intelligently, some nearly essential background reading for you would be "The Mythical Man-Month" by Fred Brooks, also useful would be "Code Complete" by Steve McConnell and "Rapid Development" by the same author. There are many others. If you haven't read at least the first one, and preferably at least some others of the genre, it is like you are trying to fight a war when you are unarmed.