MozillaZine

Full Article Attached Towards Mozilla 1.0

Tuesday June 26th, 2001

Gervase Markham recently posted his feelings on what a 1.0 release of Mozilla would be. Gerv has sent us the follow-up to that posting, including much of the feedback he received. To read it, click the full article link. Once you have read through it, we welcome you to post your feelings on what you think a 1.0 release would have. [As Gerv says, please don't post your favorite list of bugs, only the criteria for choosing what bugs to fix.]


#14 [INSERT TITLE HERE]

by Ugg

Wednesday June 27th, 2001 1:50 AM

You are replying to this message

My criteria (largely pulled out of you-know-where):

There should be zero crasher bugs in the main components themselves. (Crashers in third-party plugins, Java, and so on might be considered acceptable; the hypothetical "buck stops here" guy should consider each bug, or each minor component that could be buggy.)

There should be zero bugs relating to data corruption or loss, period. These problems are *not* acceptable.

The promises for standards support and compliance that have been made should be honored; if full support is impractical, full compliance should be considered acceptable, but the software *must* perform to established standards.

The standards for which support or compliance has been promised should have zero rendering bugs (or in the case of promised standards which may not have any visual effect, such as mail protocols, there should be zero bugs in the backend implementation).

There should be no memory leaks. If Mozilla must be a hog, then let it be, but it should be a *steady* hog, not one that eventually swells to the size of a house.

If these requirements seem unreasonable, consider that in recent years, the acknowledged inevitability of 1.0-release bugs has served to make buggy 1.0 products acceptable in the public eye. I believe that Mozilla should strive as much as possible to avoid this "public beta" philosophy when defining criteria for a 1.0 release.

I would suggest that window drawing performance should be *equal* to that of OS-native windows, but I don't know whether this is feasible. I would also suggest that the UI be polished as much as possible, but UI polish is difficult if not impossible to quantify.