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.]
#102 Re: [INSERT TITLE HERE]
Wednesday June 27th, 2001 6:31 PM
You are replying to this message
I think you've got the right idea - here are my somewhat more moderate suggestions.
1. API stability - absolutely critical. Mozilla needs to have stuff work between versions. Do whatever it takes - drop stuff or add simple implementations if necessary for stuff that's not ready. Specifically the theme breakage that happens is terrible. At least two themes were either suspended or delayed because they kept having to update them on weekly/monthly basis.
2. Documentation - ksozez's comments are right on the money.
3. Stability - right now I think the memory leaks are the worst thing. Bad memory leaks are just as bad as low MTBF because you end up closing the browser either way. The way I would quantify memory leaks that should be fixed is any that commonly occur - e.g. any memory leaks that happen every time you perform a common action like loading a page, pressing the back button, loading new windows, etc. This has to be my worst gripe with Mozilla, it really increases the system requirements. For example, last night I ran the random link buster on Linux and within 20-30 minutes I went from 24 -> 35+ megs of ram used. There are supposed to be some fixes the window (<a href=<http://bugzilla.mozilla.org/show_bug.cgi?id=84136>>84136</a>), but for some reason that ones not working for me yet. Obviously 10-15K leaks aren't too bad but when you're leaking 100K+ on every page load it adds up fast. Asking users to upgrade their ram is find for the techies, but is the target audience really going to go out and buy ram so they can run Mozilla or Netscape. I've seen very few crashes lately, but obviously any crashes or data corruption that occur frequently should be addressed.
4. Polish - got to agree with what's been posted earlier. Hard to establish criteria here, but things should work as expected, no pixel misalignments, text display errors, etc.
5. Performance - seems pretty good. One criteria would be to get Mac and Linux builds up to Windows level performance (especially interface speed). Mozilla on my work K6-2/333 is much slower in X (Deb unstable, 2.4 kernel) than in Windows. I found the Windows performance relatively acceptable for almost everything, so how about establishing this a metric. When <a href=<http://bugzilla.mozilla.org/show_bug.cgi?id=53486>>53486</a> lands, performance should increase slightly, but probably not to the level of Windows.
BTW, it would be really nice if Mozillazine had a preview button. With a text field this small it can be hard to tell if you've typed everything correctly.