Mozilla Schedule Update
Tuesday May 30th, 2000
Mitchell Baker, Chief Lizard Wrangler, has posted an update on what mozilla.org's plans are for M16 and M17. Basically, M16/17 are stabilization and feature cleanup milestones, and there will be a large focus on optimizing and debugging Mozilla, so that both Netscape and other groups can get a good usable base to build off of. To read the whole post, simply click the Full Article link below.
#1 About scheduling...
Wednesday May 31st, 2000 12:35 AM
I preferred the way it was done the first time. Based on a stable milestone so that I KNEW what to expect at a minimum, and what I could compare it against to look for improvements and deficiencies. A benchmark if you will. If you take a build, and then try to time a NS Beta to go public the same time as a milestone, then the NS Beta will have something the Moz Milestone doesn't, and vice versa, thus nothing to compare it to to gauge Netscape's internal progress against.
Bluntly, I'm more likely to stick with the Mozilla milestone than Netscape PR2 if they're released simultaneously without being code-concurrent (aside form Netscape's additions, mind you). These betas should be Milestone X plus Netscape features.
I agree with the above. If netscape is selling itself as Mozilla+features then obviously they need a period to get those features in and working, even if only to clean up small problems.
Myself, I'll be using Mozilla too :) W
#3 Milestone page updates
Wednesday May 31st, 2000 5:49 AM
Obviously this news is great, but it hasn't gotten into the seamonkey milestone release page that I have been checking regularly for the last couple of weeks. I really think that it is important to keep this page available and up to date to allow all those people who may not come to mozillazine to know what is going on.
Th url id the page that I am talking about is: <http://www.mozilla.org/pr…cts/seamonkey/milestones/>
#5 Re: Milestone page updates
by mitchell <email@example.com>
Wednesday May 31st, 2000 12:27 PM
Yes, you're absolutely right these pages should be updated. The contributor who was doing this stopped a while ago, and we haven't found a replacement yet. I'm thinking maybe mozilla.org staff should do this; I just need to figure out what we shouldn't do instead:-) Or find another contributor who's close enough to the project to be able to keep these pages updated. Anyone got an idea?
#4 Memory use and the Mozilla platform
Wednesday May 31st, 2000 8:10 AM
In my opinion, memory use ("bloat") is perhaps the single most important issue to be addressed during the approach to Mozilla 1.0. Although the browser itself could perhaps get away with the 20MB+ bloat size at the moment, the issue affects other applications which may use Mozilla as a platform. Obviously, you wouldn't want to run every Mozilla application within the browser process. It would not be a very responsive UI and browser would take all the applications down with it when it crashes. If Mozilla is successful as a platform, multiple Mozilla processes are likely to be running simultaneosly. This means that even with shared libraries, things like startup memory overhead and string bloat will be an important issue.
#6 Re: Memory use and the Mozilla platform
Wednesday May 31st, 2000 12:33 PM
I presume "1.0" is a theoretical version number because it looks like Mozilla is sticking with Milestones (I've seen up to M30 mentioned on mozilla.org) and date-based build numbers :-)
It looks like bloat is indeed one of the main things that the Mozilla project will be looking at for M16/M17, though if their leak figure of 4K in Tinderbox is truly correct, then that's impressive for such a large project.
I, personally, would like to see a downloadable optimised, stripped and maybe devoid-of-mail/news/editor version of Mozilla in addition to the debug versions, at least for the Milestone releases. That way, we'd have a lean and mean Mozilla for every day browsing and the debug/bloat-a-rama version for reporting bugs.
#7 Re: Re: Memory use and the Mozilla platform
Wednesday May 31st, 2000 1:27 PM
I too would love to see an optimized browser-only version of the Milestone builds.
Many uninitiated web surfers have tried out Mozilla and dropped it due to its bloat. If memory usage improves over the next few Milestone builds, I'll be able to recommend Mozilla to these people with more confidence.
#9 Another vote for browser-only milestone
Thursday June 1st, 2000 4:14 PM
I guess it's possible maybe to create your own browser-only build by pulling certain files out of the dir.
What those files are, I have no idea.
If there were a browser-only build though, that'd be cool, and maybe faster too... :)
#10 Re: Another vote for browser-only milestone
Friday June 2nd, 2000 7:18 AM
Well, you can easily grab the sources and compile them yourself so that you're left with just the browser. However, doing this for every nightly release is a pain, especially if you have dial-up access (like myself).
I wonder just how much faster a browser-only build would be? With Navigator 4.x under Linux, I never saw much of a difference between Communicator and stand-alone Navigator in terms of performance.
#11 Minimal difference in speed.
Friday June 2nd, 2000 10:34 AM
In execution speed that is. Think about it, do you think that MOzilla is using any non-browser code when you're just browsing? No! There are too many fellow propellerheads to miss that opportunity for optimization. =-]
What about loading speed, though? Mozilla's loading time is positively horrid.
Again, I hope we see this improve over the next few milestones.
#13 Re: Re: Minimal difference in speed.
Friday June 2nd, 2000 12:39 PM
It might help loading speed. If it were browser only the pakage would be smaller.
Too bad that the editor cannot be really removed currently:
#14 Re: Another vote for browser-only milestone
Friday June 2nd, 2000 10:13 PM
"Use the source, Luke." The package lists in mozilla/xpinstall/packager enumerate the files that are part of the xpcom core, the browser, and mail components.
An easier way to get a browser-only installation it is to run the installer, choose custom, and deselect everything that isn't browser.
"Browser-only" currently includes editor XUL, but that's a trivial amount of space. It has to include the editor libraries to make text areas work. When ender-lite comes on line we may revist whether it makes sense to split the editor out as a separate installable component.
#8 Re: Re: Memory use and the Mozilla platform
Wednesday May 31st, 2000 9:29 PM
The optimised build is being optimised further. The nightlies are suppost to be optimised. "Devoid" of mail/news shouldn't be too hard and "devoid" of editor is being worked on last I heard (the browser and mail-news components currently uses the editor ala text mode).