Mozilla Milestone 14 Awaits

Anderson Silva (among others) zapped us the news that you can now grab Mozilla's M14 release (Seamonkey). The Mozilla Organization's site doesn't yet reflect M14's availability, but it will soon. For now, here are the release notes. So grab, test, and gripe -- bug reports will only make the Mozilla browser better.

Comments

Re:Mirrors (Where?)

[fluffhead]

Check out http://www.mozilla.org/mirrors.html for a list of download mirrors.

#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak

Use a talkback build

[linuxci]

If you're using Windows or Linux please consider downloading a talkback build (they have talkback in their filename) this'll automatically send back crash data (with your permission - a box will appear first) to the Mozilla team which will help them track down the main causes for Mozilla to crash.

BTW the source code for M14 should follow on the FTP site soon. If you can buld for other platforms please do so and contribute your builds back to Mozilla. See here for details of packaging your own milestone build for your platform.
--
Make use of your spare CPU time!

M14 already? What happened?

[drivers]

But there are still 500 bugs targeted for M14

I saw M13 get whittled down to zaroo boogs, then it came out, I assumed the same for M14. Does this have anything to do with Netscape wanting to get a Communicator 6.0 beta out ASAP?

Don`t forget about Mozillazine!

[Sits]

Mozillazine is a website manned by helpful volunteers hoping to make Mozilla the best browser possible. If you are unsure as to how to get started bug testing, I recommend stopping by #mozillazine for a friendly chat.

Bug Reports

[asa]

Mozilla releases these milestone checkpoints with the hopes that lots of people will take a look and give some feedback. Bug reports are the best way to give this feedback. Mozilla's bug database Bugzilla (located at http://bugzilla.mozilla.org ) provides some really nice tools for reporting bugs and feature requests. Before reporting any bugs it is a good idea to give the database a query to see if your bug has already been reported. This will save mozilla QA a lot of time weeding through duplicate bug reports. You can search the database at http://bugzilla.mozilla.org/query.cgi . Start off with simple searches in the Description field. If that yields too many bugs to weed through you might add more to the search. If you find your bug reported please add any relevant comments to that bug report. If you find that your bug is not reported then please take a quick glance at the bug reporting guidelines before making your report. These guidelines will help you report a bug that developers and QA can track down and fix more swiftly. The bug reporting guidelines ca be found at http://www.mozilla.org/quality/bug-writing-guideli nes.html . If you are new to the process you might try the new Bugzilla Helper which will guide you through the process. Remember that the better the report the more quickly it will get confirmed, assigned and fixed. Thanks, and enjoy M14 (for those that like to stay on the bleeding edge, M15 cycle nightly builds have been available for a few days now.)

Asa
external QA on the Mozilla project

Protocols supported

[linuxci]

As well as the protocols you'd expect to be supported some outside contributors have also added the daytime protocol (although they've wrongly called it the datetime protocol) and the finger protocol. There has also been work at implementing the IRC protocol.

Try clicking on the following links in Mozilla:

Finger

Daytime (site may be down in a few hours though so if it doesn't load it's probably not mozilla)

I can see a use for the finger protocol (if all major web browsers end up supporting it there'd be no need for those finger CGI scripts that people use to view .plan files on the web)

--
Make use of your spare CPU time!

testing vs. personal use

[SEAL]

Why should you download the latest Mozilla milestone?
Don't say for personal use... it is still in a testing phase.
You have to remember that the developers are counting on your input.
Pour over the little details and give them feedback.
Some of the crash bugs need to be endured - don't go screaming back to I.E.
Hot off the press builds (nightlies) should probably stay with the developers, however, who have more
Grits to deal with the situation.
Down to the last milestone, you have to think like a tester, not an end user.
Your feedback is important to the Mozilla team.
Pants off to them... er whoops ;) Hats off.

SEAL

(sorry I couldn't resist...)

Re:This better not be M14

[Slothy]

The problem here is that you're using an SMP box and Mozilla is not yet thread-safe, though I have NO idea why they don't put this is big bold letters on the M13/14 pages. So people with a single CPU have a fairly rock-solid browser, and people with SMP boxes think this should probably be Milestone 3.

The bug for this is:

http://bugzilla.mozilla.org/show_bug.cgi?id=2155 6

OT: Slashdot speed (was 'any hope for the speed?')

[orcrist]

I'm very surprised that Rob hasn't implemented Gzip::Chain for Slashdot. For those of you who don't now what that is, it's a modperl handler which gzips the output before sending it. This takes advantage of the single most unused feature of Unix Netscape, namely gunzipping pages on the fly. Given the huge amounts of text on most Slashdot pages, as well as the above-average use of Unix Netscapes by Slashdot visitors, I figure this would be a very significant improvement in speed for said users, not to mention reduced bandwidth usage. Of course, I'm not sure how much CPU time that would require on the Slashdot servers, though I assume bandwidth is more of a bottleneck.

Just a thought which I keep on meaning to mail Rob...

Chris