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

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?

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?

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

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?

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.).

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. :-)

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

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

James

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 www.test.com and not www.test.net or 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.

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.

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

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