MozillaZine

Full Article Attached The Road to Mozilla 1.0

Monday April 8th, 2002

Mitchell Baker writes: "A few Mozilla 1.0-related steps will take place before Mozilla 1.0 is itself released. The next couple of steps are outlined in the linked article." Click the Full Article link to check out what's coming up including info on release candidates and more.


#1 Erste ;-)

by skeeter

Monday April 8th, 2002 10:53 PM

Reply to this message

Nah, das hoert sich gut an, dann hier damit.

#2 And then...?

by emlyn

Monday April 8th, 2002 11:35 PM

Reply to this message

Are there any further thoughts on codebase management after the tree is riven in two?

Will Mozila.org make binaries available? If so, will it be from the branch or the trunk, or both? What further features will be checked into the trunk, and will the branch miss out altogether? How low does a risk need to be before it is acceptable for the branch?

And most importantly, if interest in Mozilla zooms up, who will write the page explaining the difference between a branch and a truck to the newbies and how well will they write it?

#3 Re: And then...?

by Gerv

Tuesday April 9th, 2002 12:29 AM

Reply to this message

> Are there any further thoughts on codebase management after the tree is riven in two?

It's all in the roadmap.

> Will Mozila.org make binaries available? If so, will it be from the branch or the trunk, or both?

As with any other branch, there will be nightlies from both the branch and the trunk.

> What further features will be checked into the trunk, and will the branch miss out altogether?

Basically, "none". But that's a decision for drivers.

> How low does a risk need to be before it is acceptable for the branch?

That's a decision for drivers.

> And most importantly, if interest in Mozilla zooms up, who will write > the page explaining the difference between a branch and a truck to > the newbies and how well will they write it?

You? :-)

Gerv

#4 Re: And then...?

by emlyn

Tuesday April 9th, 2002 1:34 AM

Reply to this message

>> Will Mozila.org make binaries available? If so, will it be from the branch >> or the trunk, or both? > >As with any other branch, there will be nightlies from both the >branch and the trunk.

Right, but what will be linked from the Mozilla.org front page? What will you tell testers to download?

>> What further features will be checked into the trunk, and will >> the branch miss out altogether? > >Basically, "none". But that's a decision for drivers.

Does that mean no new trunk features or no new branch features? Frozen branches I can live with, but no cool new trunk features every week? How would I spend my afternoons?

-Emlyn

#5 Re: Re: And then...?

by Gerv

Tuesday April 9th, 2002 2:24 AM

Reply to this message

> Right, but what will be linked from the Mozilla.org front page? > What will you tell testers to download?

It depends what needs testing :-) I expect the focus to be on the branch for a while yet.

> Does that mean no new trunk features or no new branch features?

Given that the branch is supposed to be stable, which do you think? :-)

Gerv

#15 And then... (writing a guide for newbies)

by Tom_S <schluter@bright.net>

Tuesday April 9th, 2002 11:56 AM

Reply to this message

Ahem... as a relative newbie (I have no idea what the gold stars mean on the branch status page)... I\'d be willing to take a stab at it.

From my limited knowledge of the project I can share why I use Moz (decidedly fewer security vulns than the default proggie that comes with Win98SE), The pros and cons of choosing the branch (leading or bleeding edge?) or trunk (stability?), and where to find them (appropriate URLs), and a reminder to uninstall previous versions to prevent version collision.

Perhaps the thing is written already....

Tom

#25 Re: And then... (writing a guide for newbies)

by johnlar <johnlar@tfn.net>

Tuesday April 9th, 2002 5:12 PM

Reply to this message

Actually branches arn't bleeding edge, the trunk is. Here is how it works. Trunk opens for new code (bleeding edge)Trunk gets closed to all but bugfixes, branch gets cut (stabilization happends on the branch) at the same time trunk is reopen to new bleeding edge code for the the milestone after the branch milestone, new code won't get put in the branch, any bugfixes that get put in branch also get put in trunk if at all possible. Milestone gets released from branch, repeat.

#6 Branch for RC1 only?

by itomkins

Tuesday April 9th, 2002 3:11 AM

Reply to this message

I am slightly unclear on the purpose of this branch. Is this new branch just for RC1? Will the subsequent RC2 or 1.0 be a further development of this branch or a new branch off the trunk?

#26 Re: Branch for RC1 only?

by mitchell <mitchell@mozilla.org>

Tuesday April 9th, 2002 5:20 PM

Reply to this message

Our plan is that the RC1 branch will be the branch from which RC2 (if necessary) and ultimately Mozilla 1.0 will be released. We do not plan to return to the trunk for either RC2 or 1.0.

Mitchell

#7 String freeze

by sebol

Tuesday April 9th, 2002 3:50 AM

Reply to this message

dont change string after RC1... please.........

#18 Re: String Freeze

by grahams

Tuesday April 9th, 2002 1:53 PM

Reply to this message

What is the difference? Shouldn't the User Agent string actually reflect what user agent the user is using?

#20 Re: String Freeze

by mpercy

Tuesday April 9th, 2002 2:18 PM

Reply to this message

I think he is talking about localized strings for translation into other languages. String changes really make it hard to keep up.

#27 Re: String freeze

by asa <asa@mozilla.org>

Tuesday April 9th, 2002 5:56 PM

Reply to this message

Changes to localized strings will be very minimal. It should be safe to start a localization now and adjust to any minor changes in time for the final 1.0 release.

--Asa

#8 'Branch' misleading?

by SmileyBen

Tuesday April 9th, 2002 4:57 AM

Reply to this message

I'm assuming that the use of the word 'branch' is slightly misleading... In the past, milestones have been branched off the tree so that new features could be added to the trunk, and potential regressions created, whilst simultaneously stabilising the branch in preparation for a milestone release which is good enough to be widely tested and find more subtle bugs. But since RC1 will surely be feature-complete, all that's going to happen will be bug-squishing, no? So nothing will really happen to the trunk, presumably RC2, RC3 (or whatever) and then 1.0 will be built off the bug-squishing branch, as the branch gets better and better: without new features etc. all that will happen is bug-fixing, and no new bugs will be introduced.

All of which amounts to the trunk being largely ignored for a couple of / few weeks... Is that about right?

#28 Re: 'Branch' misleading?

by asa <asa@mozilla.org>

Tuesday April 9th, 2002 6:04 PM

Reply to this message

That's mostly correct, with one major exception. The trunk is expected to be quite active. We've been saying no to a number of large changes and new features for a while now and it is likely that soon after we branch many of those will begin to be implemented on the trunk.

--Asa

#9 take your time, don't rush it now

by jilles

Tuesday April 9th, 2002 7:09 AM

Reply to this message

I would like to urge the Mozilla developers not to rush it out now. A few weeks more on four years of development won't hurt anyone. You're nearly there, however bugs are going to be found in this RC1 candidate and fixing them before releasing 1.0 is important IMHO. Mozilla 1.0 is going to looked at and judged by a large group of people, so it is important that everything works perfectly.

The set of features offered by Mozilla has been stable and very usable for months but there have been regressions, bugs and annoyances that advanced users can live with but would turn away interested IE users (e.g. the recent %20 bug in imported bookmarks, the threading/sorting issues in mail/news, etc.).

#10 Optimizations?

by Kirby

Tuesday April 9th, 2002 8:14 AM

Reply to this message

Will Mozilla's speed be improved further in RC1? Even though Mozilla is very fast on my Athlon 1,4 Ghz + 128 MB RAM, I heard from some people with a Pentium 2 450 that they're still having problems with Mozilla's speed. It would be great if Mozilla runs just as fast as (or faster than) IE on a Pentium 233 with 48 MB RAM. :-)

#11 Re: Optimizations?

by mattdm <mattdm@mattdm.org>

Tuesday April 9th, 2002 8:46 AM

Reply to this message

Works fine on my PIII 450 -- starts in about 9 seconds, which is twice what NS 4.7x takes, but once it's running, it's plenty fast.

#14 Re: Re: Optimizations?

by rgelb <nospam@nospam.com>

Tuesday April 9th, 2002 10:44 AM

Reply to this message

>>Works fine on my PIII 450 -- starts in about 9 seconds

9 seconds to start a browser is not fine. Has anyone compiled moz code for the actual chip? What were the results.

#17 Re: Re: Re: Optimizations?

by macpeep

Tuesday April 9th, 2002 12:25 PM

Reply to this message

RAM makes the difference.. NS 4.7x starts in about 3 seconds for me on IDE drives, Win2K, 500MHz Athlon with 384MB RAM. Mozilla, I haven't timed lately but it's about the same. IE starts instantaneously (that is, faster than Mozilla opens a new browser window when it's already running). And please, spare me the usual propaganda about preloading, being part of the OS, spelling Microsoft with $'s and all that other stuff. The bottom line is that startup time is not an issue on any of those. It really doesn't matter on today's systems. Same for runtime speed. I don't really see a problem with Mozilla's speed and I'm not on a fast system by any standards. If anything, I guess one could complain about Mozilla using a lot of RAM...

#21 Re:

by PsychoCS

Tuesday April 9th, 2002 3:29 PM

Reply to this message

It starts in 2-4 seconds on my Win2k PII 450MHz, depending on RAM used etc. on a cold start, and about 1-2 seconds on a warm start...possibly even faster than IE6, but I have 384 MB of RAM as well.

#22 compile time

by dipa

Tuesday April 9th, 2002 3:30 PM

Reply to this message

If I understand you correctly, you asked for compilation time. I recently compiled Mozilla on my K6-III/400 (similar to PIII-450 on integer performance) in 50 minutes.

#31 impossible?

by niner

Wednesday April 10th, 2002 1:39 AM

Reply to this message

Are you sure that you compiled the whole thing?

Okay I've some optional parts turned on (e.g. MathML), but still this can't make so much difference that my Athlon XP 1800+ still takes 50 minutes to compile a complete Mozilla from scratch and my PII 450 took several hours. Even the daily CVS update took about an hour on the old machine.

#12 A new UC1 section on mozilla.org mainpage

by treebeard <treebeard@treebeard.net>

Tuesday April 9th, 2002 9:09 AM

Reply to this message

I suggest either a new section for the RC1 latest builds or renaming the current "Nightly Builds" to "Release Candidate 1 Nightly Builds" so everyone knows just what they are testing. Especially if news of RC1 ( which I expect will be fairly widely noted ) attracts new testers

#13 Re: A new UC1 section on mozilla.org mainpage

by requa

Tuesday April 9th, 2002 9:32 AM

Reply to this message

For further access simplification, I'd suggest moving all of the dated nightly build folders on the ftp server into a subfolder of pub/mozilla/nightly/dated. This lengthy list of numbered folders is confusing to those who are unfamiliar with the build numbering system, and who would be better served by a simple route to "latest-trunk" and "latest-RC1" folders.

#19 good idea

by niner

Tuesday April 9th, 2002 2:06 PM

Reply to this message

This would be nice indeed. I think most people use the "latest" directories so making the numbered directories subdirectories of an archive would make it easier.

#16 Nice

by Kovu <Kovu401@netscape.net>

Tuesday April 9th, 2002 11:56 AM

Reply to this message

Good preemptive strike against really silly questions, Mitchell. :)

James

#23 Mozilla is still too buggy to approach 1.0

by TGOS

Tuesday April 9th, 2002 3:45 PM

Reply to this message

Still the caret overlaps the last character in all input form fields, as well in the URL bar, this bug is very annoying and unprofessional, especially since it's known since nearly a year and nobody takes care of it.

Still you sometimes open a second window by clicking on a HTML file, a link in another application or by clicking on the Mozilla shortcut again (it doesn't matter how you open it, as long as you don't hit CTRL+N, choose new window from file menu or open a link within Mozilla in a new window) and the newly open Window can't gain focus (you can't enter anything into the URL bar for example, the caret will never appear there, no matter how often you click there). This bug is also not new and has not been fixed.

Still Mozilla opens the download manager, if you store a picture from a webpage (or one directly loaded form the server) to disk, even though no download takes place, but the picture is stored there form memory (browsers like IE or Opera don't do that).

Mozilla's speed is also still suffering if you load more than 2 MB of HTML data. That the speed will decreases in case of such a big page is normal, but neither in IE, nor in Opera it decreases that much.

You can still not disable the guessing of DNS names. If you enter test into the URL bar and hit enter, Mozilla will add www. to front and .com to the end. I don't want that this happens, because I use Mozillas keyword feature to search on Google. If I enter multiple words into the URL bar and hit enter, Mozilla opens Google and displays the search results for this word, which is really nice. But if I enter a single word there, it will not work that's to guessing of DNS addresses. And who says I want to see <http://www.test.com> and not <http://www.test.net> or <http://www.test.org>? This autoguessing is completely nonsense and Opera allows you fine-tune it for your needs (e.g. it can also try to add a country domain if you like) or to disable it completely, why isn't that possible in Mozilla? (Yes, I have requested this feature!)

There are still all kind of little GUI flaws, too many to name them all in a single post. There are still out-of-the-blue crashes, that don't happen at any specific page or action, they just happen and are not reproducible (talkback has been used, but it seems nobody can fix these).

Actually I hoped that Mozilla gets a real download manager, one like Opera and not one like IE. If you run multiple, not a new window should open for every download, but both downloads should be displayed in a single download manger window, so you can run 20 downloads at once, without cluttering up your screen. If no downloads are running anymore, the window may close automatically if the user choses that(otherwise it opens with the first download and stays open till the user closes it, however, still running downloads are stopped if the user closes it manually) and complete downloads are removed from the window (unless the user chose to keep them there). Incompletely downloads should not be removed from that window (unless the user wishes that) and you should be able to open it again through the Window menu. If you open it and there are incomplete downloads, you can select them and Mozilla will try to resume them if possible (no problem via FTP, also not a problem on many HTTP servers). If that fails, you can select them and hit redownload, to download from the beginning again. You can also select a running download and interrupt it (at your own risk, as you may not be able to resume it later on). If complete downloads are kept there, you can also download them again if you like (e.g. if you suspect that the file should have changed in the meantime). And if the user wishes it, new downloads are not started at the moment they are added to the download manager window (which is default), but only scheduled. You can then later on click them and choose download or click auto-download, which will go down the list and retrieve everything that still isn't complete (those that were not started at all so far and those that needs to be resumed or downloaded from the start if resuming fails), however, never more downloads at once than you selected in the settings and never trying to download the same file more often than a selected limit (if fails several times, skip it and go to the next one). Such a download manager would even be better than the one of Opera and the one of Opera is the best browser download manager there is so far.

Hell, not even the current input window here is working correctly. Whenever I hit the bottom line and anotehr line is added, I don't see it, because Mozilla forgets to automatically scroll this window upwards. It will only scroll it upwards after I typed maybe half of the next line blindly. But that may just be the fault of the current nightly build.

I could go on forever here, as I know far more annoying bugs like that and you can say a lot about Micro$oft's IE or Opera, but both never released a release version that was having so obvious bugs, that a tester will discover after 15 minutes testing and that had been reported as bugs so often.

#24 Googling

by shin

Tuesday April 9th, 2002 4:49 PM

Reply to this message

> You can still not disable the guessing of DNS names. If you enter test into the URL bar and hit enter, Mozilla will add www. to front and .com to the end. I don't want that this happens, because I use Mozillas keyword feature to search on Google. If I enter multiple words into the URL bar and hit enter, Mozilla opens Google and displays the search results for this word, which is really nice. But if I enter a single word there, it will not work that's to guessing of DNS addresses. And who says I want to see <http://www.test.com> and not <http://www.test.net> or <http://www.test.org>?

For Google, you actually have to hit UP then Enter, not Enter only. The only bug I see in this paragraph is that of the multiple words: when I type multiple words and hit Enter it should not think this is an URL, but rather consider I typed keywords.

#29 Re: Googling

by TGOS

Tuesday April 9th, 2002 9:46 PM

Reply to this message

When I hit up, nothing happens at all, because I have "show internet search engine" disabled and I want to keep it disabled. Maybe I even want to disable the URL pulldown menu as a whole.

I know how I can get Mozilla to use keywords for a single word, just type "keyword:" in front. E.g. if I type "test", I end up on <http://www.test.com>, but if I type "keyword:test", I see Google's search result for test.

The bug is, that you can't disable it. Who says a browser shall add www. and .com to the front/end of what you entered in the URL bar? Maybe someone living in UK would rather like co.uk to be added at the end. And at university, the DNS server DOES give valid results for addresses that do NOT have any top-domain. E.g. if I enter "stundents", I end up at the students webpage with a normal browser (the DNS server will return a valid server address for students). Not so with Mozilla! With Mozilla I end up at <http://www.students.com.>

#35 whitehouse.com

by amutch

Thursday April 11th, 2002 10:32 AM

Reply to this message

Or how about a kid using the browser who enters "whitehouse" into the URL bar. If you don't think kids don't do this, you haven't seen how kids use the Internet. Try that in Mozilla and see where "whitehouse.com" takes you.

#36 Re: whitehouse.com

by TGOS

Thursday April 11th, 2002 6:45 PM

Reply to this message

Just entered "whitehouse" and nothing else into the URL bar and ended up on an interesting page. But hey, see the positive sides, parents can skip the "flowers and bees" after their children were on that page. Well, if you are afraid of that, you actually have to monitor your children every second while they are online. Also not quite on-topic here, but I think the earlier parents are forced to to have "the talk" with their children, the better. Studies showed that children who know a lot about sex very early are much less likely to ever accidentally get pregnant or catch a sexual transmitted diseas, because the myth that children who know a lot about sex will also have sex early, is just that: a myth!

But my point is that it must be really easily to disable this feature. There is some code that adds these two parts to each URL that seems to not be valid. All that developers must add is a boolean variable:

if (urlNotValid && autoCompleteSet) { // autocomplete URL }

And in the preferences screen people can decide if autoCompleteSet is true or not.

#30 Re: Re: Wrong.

by zontar

Tuesday April 9th, 2002 10:41 PM

Reply to this message

Well, that's odd, as soon as I start typing something in, I get the little pulldown with the "G" logo and the text "Search for..."

#32 Not wrong at all

by TGOS

Wednesday April 10th, 2002 5:37 PM

Reply to this message

But I don\\\'t want to have this URL pull down menu, so I disabled it. And I also don\\\'t want to click anywhere or hit the up key. And most important, I don\\\'t want to use Mozilla\\\'s build in Google search, because I search via a customized GET request, so I have 100 results a page, as well as other options enabled (and that even though I have cookies disabled in Mozilla).

What I want that Mozilla uses exactly what I typed into the URL bar and asks the DNS server for an address. That\\\'s what IE does, that\\\'s what Opera does, that\\\'s what the good old Netscape did, that\\\'s what every browser on this planet does, except Mozilla and Netscape 6.x

At my university \\\"http://stundents\\\" is a valid URL within the local network! If I use a normal browser and enter \\\"students\\\", I come to the sutdents page, but in Mozilla I end up at <http://www.students.com>, a page I never wanted to go! If I had wanted that, I had typed it there.

So Mozilla should always take the address exactly like I typed it into the URL bar, ask the DNS server for an address and if this DNS server does not return a valid result, then Mozilla may either:

1) Try to guess the address if the user allowed this. This means it adds \\\"www.\\\" to front and adds something to the end like \\\".org\\\", \\\".net\\\", \\\".gov\\\", \\\".com\\\" or anything else the user WISHES to be added, in the order the users wishes that Mozilla tries it and takes the first match. Only if none of all work, an error is displayed.

2) Or alternatively, fire up the keyword URL, with the URL bar data placed into the URL at the selected position. Additionaly Mozilla should allow users to customize the keyword URL (that by defaults searches via Netscape.com and visits the first page found) within the preferences screen.

#33 Re: Re: Wrong.

by zontar

Wednesday April 10th, 2002 8:39 PM

Reply to this message

Well, if I type "http://zontar/" into my URL bar, I get the server running on my box, and if I type "http://boofhead/" I get the one on my wife's machine.

#34 Re: Re: Wrong.

by zontar

Wednesday April 10th, 2002 8:41 PM

Reply to this message

Crap... those were supposed to be: h t t p : / / z o n t a r / and h t t p : / / b o o f h e a d / respectively. Darned HTML-zapper code used here is a little ridiculous sometimes.

#37 getting bug reports from users?

by feepcreature

Friday April 12th, 2002 6:48 AM

Reply to this message

Is the development community interested in bug reports from the (hopefully) larger number of users who will try to use RC1?

If so, what steps do you think are appropriate to get that information? And is there anything that needs to be set up for the standard [binary] distribution (such as an invitation or explanation on the default home page)?

What I'm getting at here is that the new users will NOT be bugzilla gurus, and it is probably unrealistic to expect most of them to navigate the (initially scary) bugzilla forms. Yet they still have useful information to offer - like what bugs cause most problems for "real" users (and hinder mozilla adoption). They will also discover new bugs.

What about promoting more frequent / better advertised "bug days", bug reporting channel on chatzilla, newsgroup, web-forum? Or a simple search interface to bugzilla, to give a simpler answer to "is this a known bug" (currently the search response gives an overwhelming level of detail).

Just some half baked thoughts. I know this is a tricky problem, and I'm not sure what the answer is....

Paul

#38 getting bug reports from users?

by feepcreature

Friday April 12th, 2002 7:59 AM

Reply to this message

Is the development community interested in bug reports from the (hopefully) larger number of users who will try to use RC1?

If so, what steps do you think are appropriate to get that information? And is there anything that needs to be set up for the standard [binary] distribution (such as an invitation or explanation on the default home page)?

What I'm getting at here is that the new users will NOT be bugzilla gurus, and it is probably unrealistic to expect most of them to navigate the (initially scary) bugzilla forms. Yet they still have useful information to offer - like what bugs cause most problems for "real" users (and hinder mozilla adoption). They will also discover new bugs.

What about promoting more frequent / better advertised "bug days", bug reporting channel on chatzilla, newsgroup, web-forum? Or a simple search interface to bugzilla, to give a simpler answer to "is this a known bug" (currently the search response gives an overwhelming level of detail).

Just some half baked thoughts. I know this is a tricky problem, and I'm not sure what the answer is....

Paul