MozillaZine

Drivers Update

Friday March 29th, 2002

The mozilla.org Status Reports was updated, and included some information on what drivers@mozilla.org are up to, and what's coming up:

"drivers@mozilla.org approved checkins for over 240 bugs this last week. We've taken a few more big-ticket items and have a couple to go. drivers will be ramping down this next week and actively soliciting fixes that we need to branch and have a Release Candidate 1 sometime (hopefully) late next week. We need to get RC1 out there quickly and get feedback on all the changes we've taken since 0.9.9 and at the same time we need the release to stand up so that users will put enough hours on it to give meaningful feedback. Please help us to get the builds into good shape over this next week with particular attention to recent regressions and topcrash+ bugs."


#1 RC1, wow

by Kovu <Kovu401@netscape.net>

Friday March 29th, 2002 1:00 AM

Reply to this message

I never thought I'd see the terms "RC1" and "Mozilla" in the same sentence. The sky is falling!

#2 RC1, or 0.9.10?

by tepples <tepples@spamcop.net>

Friday March 29th, 2002 12:50 PM

Reply to this message

What's the difference between a "Release Candidate 1" and an "0.9.10"?

And will the fifth release candidate include a distributed encryption cracker <http://www.distributed.net/rc5/> ?

#3 RC = release candidate

by Kovu <Kovu401@netscape.net>

Friday March 29th, 2002 1:01 PM

Reply to this message

An RC is the final version of a software in its final bugtesting phase. A .9.10 would not be an RC, it would be yet another milestone cycle.

JR

#4 Re: RC = release candidate

by tny

Friday March 29th, 2002 1:31 PM

Reply to this message

I think Y H B T .

#10 errr?

by Kovu <Kovu401@netscape.net>

Friday March 29th, 2002 7:27 PM

Reply to this message

<sheepish> Wassa? (YHBT) </sheepish>

#12 YHBT

by jonasj

Friday March 29th, 2002 8:29 PM

Reply to this message

You Have Been Trolled.

#13 Jargon

by tny

Friday March 29th, 2002 8:31 PM

Reply to this message

See <http://www.tuxedo.org/smr/jargon/> and look for YHBT. It means you have been trolled - i.e., you\'ve taken a troll too seriously.

Anyway, it is good to see things like RC1 and 1.0 talked about as being in the near future.

#14 I wasn't exactly trolling

by tepples <tepples@spamcop.net>

Friday March 29th, 2002 8:44 PM

Reply to this message

I wasn't exactly intending to troll the board. I was only wondering how this "release candidate" is different from any other "milestone", especially in light of ralphmellor's thread below.

#16 Re: RC1, or 0.9.10?

by Tayto <gary@netsoc.tcd.ie>

Saturday March 30th, 2002 7:26 AM

Reply to this message

New milestones are characterised by feature additions, followed by bug fixing, branching and stabilisation. There SHOULD be almost nothing in the way of new features added between RC1 and the final 1.0, therefore it should be considered as a final stabilisation phase before the real 1.0 is released.

I would be pretty sure that the main reason for the release of an RC1 is to get a large number of people to use this build. Then the talkback reports can be used to squelch the topcrashes, before final release.

Gary.

#5 Is calling it RC1 a big and unnecessary PR risk?

by ralphmellor

Friday March 29th, 2002 5:54 PM

Reply to this message

From the above it appears that the current plan is to cut, within the next week or so, a branch that will be called "RC1". But it seems pretty clear that it won't really be a "Release Candidate" in the normal sense of the term, ie it won't be nearly good enough to be renamed as the unqualified 1.0. I was struck by this, and I began to reflect on what it might mean.

First, I'll note that I have jumped to the conclusion that the "release candidate" label is intended mostly to get people to take the release more seriously than might otherwise be the case. I certianly agree that it would be smart to emphasize the significance of this upcoming 1.0 cut to users/testers. I could also understand that for internal reasons, there needs to be a release candidate in the stated timeframe, even if everyone knows it probably won't cut it.

However, I think the public label "Release Candidate" will have at least as big an impact on the press as it would on users, and I wonder if this has been carefully considered. I would expect the tech press to treat it as a genuine "Release Candidate", which means that A) they will review this rather than a release a couple weeks later and B) they will argue (despite any disclaimer text Mozilla might write) that it is more representative of Mozilla's self-defined standard for quality than it really is. Unless RC1 is more stable than one can reasonably expect, this twin effect could very likely result in a lot of unnecessary negative press. Perhaps this is a good thing; there might then be another round of press once a much better RC2 or RC3 comes along. But maybe not. My point here is to ask, "has mozilla.org thought about the press coverage consequences of an inappropriate RC1 label?"

-- ralph

#6 Re: Is calling it RC1 a big and unnecessary PR ris

by johnlar <johnlar@tfn.net>

Friday March 29th, 2002 6:10 PM

Reply to this message

There are very few noticible bugs left, one of the last major ones, the minimization problem was fixed yesterday. I seriously doupt the press will find much wrong with this release. But believe it or not, mozilla RC1 is named so that it will get many eyes checking for bugs. Because believe it or not, mozilla is more concerned about being a good product than it is with press releases, as in it would love to have the press point out small bugs that havn't been noticed before by the development community (the average mozilla bug tester uses mozilla in a completly different way than the average news main stream press reporter would.) Therefor new bugs will get notice and fixed in time for the final release.

#8 Is calling it RC1 a big and unnecessary PR risk?

by ralphmellor

Friday March 29th, 2002 6:34 PM

Reply to this message

> There are very few noticible bugs left

0.9.9 works great for me.

> I seriously doupt the press will find much wrong with this release.

I agree. But our doubts might be wrong.

> mozilla RC1 is named so that it will > get many eyes checking for bugs.

Agreed. The end (attracting many eyes) is appropriate. I am calling in to question the means (apparently incorrect use of the label "Release Candidate").

> [mozilla.org] would love to have the press point out > small bugs that havn't been noticed before by the > development community (the average mozilla bug tester > uses mozilla in a completly different way than the > average news main stream press reporter would.) > Therefor new bugs will get notice and fixed in time > for the final release.

Good point.

I still wonder if mozilla.org is misusing the term "Release Candidate" (your comments suggest you think they are) and I still wonder if they are considering what will happen if they get unlucky regression wise.

-- ralph

#9 Re: Is calling it RC1 a big and unnecessary PR ris

by Kovu <Kovu401@netscape.net>

Friday March 29th, 2002 7:25 PM

Reply to this message

I might note that the differences between Windows XP RC1 and the final release were fairly significant.

Honestly, no one's going to care if RC1 is a little buggy, it's light years past the Netscape 6 release, which was bashed very badly by just about everybody.

I might also note that based on the bad reviews of Netscape 6 PR1, I had my publisher yank "Netscape 6 For Dummies".

I guess I'm arguing both sides here. It IS important to make sure RC1 is a good, stable, usable program. By definition, a "release candidate" is actually a "candidate for release" and is therefore something that the releasing body supposedly thinks is worth a release. The RC stage of software is really the last chance for surprise monster bugs (like in Starship Troopers).

I do think that if 1.0 goes to RC4 or beyond, that will prove that RC1 was anything but a real "candidate for release."

#21 Re: Re: Is calling it RC1 a big and unnecessary PR

by SmileyBen

Saturday March 30th, 2002 4:38 PM

Reply to this message

I think you're right: nobody will care if it's buggy. This is a release candidate, in the normal sense of the word. What that means is that people can download it and complain that it doesn't have their favourite feature, but can't moan that it has a few bugs, which are just what release candidates are for. You can't even complain that it has /too many/ bugs, as no doubt various people will, since the point is that you keep having RCs until there aren't any. You /can/ complain about /bugs/ rather than missing features, if 1.0 has them. I don't think anybody will be happy if there are bugs in 1.0. I think Asa would even agree that whilst they're for testing, when they say something is bug-free, it should be - even if their are features people would like missing, or polish problems.

#22 Re: Re: Re: Is calling it RC1 a big and unnecessar

by asa <asa@mozilla.org>

Saturday March 30th, 2002 9:01 PM

Reply to this message

>>I think Asa would even agree that whilst they're for testing, when they say something is bug-free, it should be...

I'm not sure I understand but since it had my name in it I think I'll respond. Mozilla 1.0 is not going to be bug-free. I have never in my life used a piece of software that is bug-free and I'm sure it will spark a debate but I'd put forth the suggestion that there are no such thing as bug-free software products, at least none of any utility. Mozilla 1.0 will have bugs. If I said at any time that Mozilla 1.0 would have no bugs then I was probably really, really, really drunk or being sarcastic.

--Asa

#23 Re: Re: Re: Re: Is calling it RC1 a big and unnecessar

by bzbarsky

Saturday March 30th, 2002 9:56 PM

Reply to this message

> I'd put forth the suggestion that there are no such thing as bug-free software products, at least none of any utility.

The closest thing I know to what you describe is TeX. It's certainly got utility (most of the math papers currently getting published are written in it). There's a standing bounty for bugs. The bounty has been unclaimed for many years now.

#25 Re: bug free TeX

by gadeiros <Harald@Henkel.DAH.UUnet.DE>

Sunday March 31st, 2002 4:50 AM

Reply to this message

> The closest thing I know to what you describe is TeX. It's certainly got utility (most of the math papers currently getting published are written in it). There's a standing bounty for bugs. The bounty has been unclaimed for many years now.

That's some kind of urban myth. Donald Knuth sends a cheque between $.25 and some $300 to everybody who first points out some layout error in a publication created using TeX, the amount being dependent on the age of the publication. Yet, most people don't really take the money, but frame the cheque.

And he sent out cheques for many thousand dollars over the past years. Of course not every cheque means another undiscovered error in the TeX software, and I would agree, that it is a very stable Piece of software with very few - even small remaining - bugs. But it has a long time of development - some 20 years now - and it wasn't completely rewritten in this time.

#46 Re: bug free TeX

by crumley

Monday April 1st, 2002 2:54 PM

Reply to this message

I think you've added to the confusion about TeX and the bug bounty. I'm not an expert, but here'ss the best link that I could find: <http://www-cs-faculty.sta…u/~knuth/abcde.html#texbk>. Also, look at the top of <http://www.ctan.org/tex-a…systems/knuth/tex/tex.web>, for TeX's changelog. It looks like no errors since 1995.

Anyway, I don't think Donald Knuth ever paid bounties on "layout error in a publication created using TeX", only on errors in his own books and in TeX itself.

#24 LOL

by Kovu <Kovu401@netscape.net>

Sunday March 31st, 2002 1:53 AM

Reply to this message

I imagine 1.0 will have bugs, otherwise there would not be a 1.1, Mozilla.org would instead jump straight to 2.0. But 1.0 should be, and I assume wil be, USABLE. Hopefully remaining 1.0 bugs will be harmless and not intrude too heavily on usability.

#28 Bug-free software?

by gwalla <gwalla@despammed.com>

Sunday March 31st, 2002 5:19 PM

Reply to this message

Hello World. ;)

#27 Re: Re: Is calling it RC1 a big and unnecessary PR

by skeeter

Sunday March 31st, 2002 12:27 PM

Reply to this message

Hi

Really, no big bugs left, then what about a 100% crash every time a Mozilla browser gets near a HTML with embeded SVG files and of course the browser has the correct files in the plugin.

Over at the bug report <http://bugzilla.mozilla.org/show_bug.cgi?id=133567> they are starting to try and blame it on Adobe.

SVG is becoming larger everyday and the plugin used to work.

Yeah, RC1 and when you find a show stopper, well it is the other guys fault, not ours there are no big bugs left if if if -----

#29 Re: Re: Netscape 4.79??

by evlg

Sunday March 31st, 2002 7:40 PM

Reply to this message

To this day exist some important and embarassing bugs.

Witness lack of View Source. The problems where the top half of text is misaligned with the bottom half of the text. This happens to me on almost every scroll of a page. Oo look at the problems where images ar displayed distorted, with lines going all through them.

These problems are minor to the developers, who want gee-whiz DOM and CSS compliance. But to the average user, its downright critical. "Look at Mozilla, what a joke, it cant every write text and draw images properly!"

These things absolutely must be polished and fixed before 1.0 is released. To say that 1.0 is almost ready because there are almost no noticible bugs left is a farce.

#32 Let's all put our heads in the sand

by skeeter

Monday April 1st, 2002 1:28 AM

Reply to this message

and when you do you know what part is left sticking up in the air.

I agree with you, this idea that everything is rosy and there aren't any big bugs left can be seen in the bug that <http://bugzilla.mozilla.org/show_bug.cgi?id=133567> I reported,

Here is a paste of the last entry at this bug report

"------ Additional Comments From <Matti@epost.de> 2002-03-31 13:49 -------

Be quiet if you don't know why this bug is evangelism. You can also start a discussion why mozilla 0.9.1 Themes doesn't work in Mozilla0.9.9 Go to the newsgroups if you want discuss stupid stuff like this but don't SPAM people here. There are a lot stupid comments in bugzilla but the last one is one of the best I have ever seen. "

Can you all belive that, telling a reporter of a bug to shut up? Of course as you see there is no @mozilla.org or even @netscape.com in the commenters address. 'isms' well they start at home.

#34 Re: Let's all put our heads in the sand

by choess <choess@stwing.upenn.edu>

Monday April 1st, 2002 8:29 AM

Reply to this message

That attitude has nothing to do with believing "everything is rosy" and everything to do with the fact that you don't understand what's causing the bug and have decided to throw a tantrum over SVG breaking. I'm sorry to see this, as I greatly appreciate the stuff you've done with SVG, but please try to be informed and mature in dealing with this.

#35 Re: Re: Let's all put our heads in the sand

by skeeter

Monday April 1st, 2002 9:34 AM

Reply to this message

What is to deal with, someone wrote some code into Mozilla, that changed the way embeded and I keep stressing embeded because if one loads a SVG file, then the plugin works fine in Mozilla. There has been a change in the necko.dll and the 14 other necko.xpt files. I pointed this out, because all Mozilla browsers are affected by this and not just svg-mathml browsers.

All I've been getting is comments like the above and that Adobe is at fault.

I've done very little with Plugin SVG, because until #3 it really didn't work very well in Mozilla and I'm not interested in using IE.

But then Adobe came out with #3 and wham the right click context, where most of the controls for it are, worked. Then this came along and suddenly Adobe is a fault. Fine they couldn't read your minds and it seems that no one thought to inform them. They (Adobe) are not going to run out and write a new #4 plugin just for Mozilla or AOL, they have just finished shipping major upgrades of their products with W3C SVG as one of the new features. This means that for all Gecko users we are left sitting on the side line. If SVG was totally broken as you all seem to think perhaps this would look different, but it isn't. it is only not working in embeded files.

#41 Re: Re: Re: Let's all put our heads in the sand

by choess <choess@stwing.upenn.edu>

Monday April 1st, 2002 1:16 PM

Reply to this message

Look, this isn't that complex. Adobe used an method from an interface in their plugin. The interface was NOT frozen. Frozen interfaces are clearly denoted in the source. Interfaces that are not frozen are subject to change at any time. That interface *did* change, as Darin fixed the last important bugs before it froze for 1.0, so the plugin was no longer binary-compatible and stopped working. Looking at the scope of the changes, it looks like there is not an extensive "rewrite" to be done on the plugin; probably some minor tweaking and a recompile.

We can't halt the development process and freeze interfaces prematurely because someone decided to use them before they were done. If you still don't get why the responsibility is with Adobe to fix this problem, I again suggest that you cease complaining about it and the Mozilla developers, because it's just making you look silly and ignorant.

#42 Should I laugh or cry ?

by skeeter

Monday April 1st, 2002 2:05 PM

Reply to this message

Have you ever read this:

" Post Talkback Please keep your comments friendly! You will be shown your post after submitting it, and it cannot be changed, so make sure you've read it over. "

Or is it only a place holder for you, your comments of

"I again suggest that you cease complaining about it and the Mozilla developers, because it's just making you look silly and ignorant. "

May be the language that you feel is normal, however I don't remember using such about this problem.

It seems that the problem has been solved in that, as you say the Adobe people enabled their plugin to work for Mozilla on Windows and Linux and that it is their fault that they didn't wait. Viewer #1 hardly worked in Windows Mozilla, in Linux zilch. Viewer #2 did work a little better in Windows Mozilla and NS, in Linux zilch. Viewer #3 work very well in Windows Mozilla and NS, in Linux a beta came out for the first time and I have heard that it works quiet well. Now-- as you say there was a developement that is covered in Bug 128508 freeze nsIChannel <http://bugzilla.mozilla.org/show_bug.cgi?id=128508> . Here are a few comments from there <http://bugzilla.mozilla.o…show_bug.cgi?id=128508#c6>

"3. Lots of the 'dummy channel' implementations stub out methods with NS_OK... Even if they have [out] parameters !! Currently this isn't hurting us (?) but it's just another live land mine that someone will step on one day..."

and here is from Darin a little further down in the thread. <http://bugzilla.mozilla.o…how_bug.cgi?id=128508#c10>

"3- i believe the dummy nsIChannel impls really only need to impl nsIRequest... they impl nsIChannel for legacy reasons (i.e., loadGroup used to be an attribute on nsIChannel). maybe i can turn those into nsIRequest impls?? i hesitated to do so for fear that someone was accessing the dummy channels via the load group "

How is this related to the bug #133567 <http://bugzilla.mozilla.org/show_bug.cgi?id=133567> that I am talking about; well it comes from <http://bugzilla.mozilla.o…show_bug.cgi?id=133567#c8> it

"ok... I have an idea what happened... The last checkin to that file was done by darin and did, besides other things, do this: (it was for bug 128508 "freeze nsIChannel nsIRequest". Hm, this is the second regression from that checkin that I stumble over...)"

But as you say this whole thing is Adobe's fault and actually it probably is. If you have been over to the bug report you will find that the reporter, that's me, has okayed to mark it fixed.

#64 Not Fixed! Marked Evangelism...

by backtick

Tuesday April 2nd, 2002 10:47 AM

Reply to this message

The reason it shouldn\'t be marked \'fixed\', skeeter, is that it isn\'t. Fixed, that is. It won\'t be until ADOBE fixes it on their end. You seem to have accepted that. The point it, EVANGELISM means keeping them up to date on it, so they KNOW to fix it. THEN it can be marked \'fixed\'. See how this works? That\'s why there IS a flag for evangelism and a different flag for fixed.

#70 Yep, aber

by skeeter

Wednesday April 3rd, 2002 1:27 PM

Reply to this message

Yes, however I would hope that one can work with Adobe on this.

After all the docs on things for Mozilla are, to be nice, a little slow to get updated.

Manifesto for Mozilla 1.0 <http://www.mozilla.org/roadmap/mozilla-1.0.html> links to a plugin doc that is dated back for over a year.

Mozilla 1.0 dependencies:

* APIs o XUL 1.0 o XBL 1.0 o XPCOM o Embedding o Plugins <http://www.mozilla.org/docs/scripting-plugins.html>

The above link leads to a doc from August of last year. Which has information on setting up your plugin to work with Mozilla .0.9.2 and NS 6

"August 31, 2001 This article applies to Mozilla versions 0.9.2 and higher and Netscape versions 6.1 and higher. It does not cover Netscape 6 and 6.01 "

The above is a paste from that link on Mozilla 1.0 Manifesto on getting plugins to work.

#57 You what?

by leafdigital

Tuesday April 2nd, 2002 7:09 AM

Reply to this message

Could you give a bug number for this problem?

As an 'average user' I've been very concerned with certain Mozilla problems (primarily the way textfields kind of didn't work at all correctly), but these have mostly been fixed. (I think there are still some glitches but they're really small.)

I have *never* seen either of the problems you described: View Source works just fine (albeit reloading the page, though that one's just been fixed I think) and text displays correctly here and on my home machine. It always has.

--sam

#15 Unclear to me

by SubtleRebel <mark@ky.net>

Saturday March 30th, 2002 3:44 AM

Reply to this message

"But it seems pretty clear that it won't really be a "Release Candidate" in the normal sense of the term, ie it won't be nearly good enough to be renamed as the unqualified 1.0."

Why do you say that it is clear that RC1 will not be nearly good enough to be renamed as the unqualified 1.0?

Which bugs do you believe MUST be fixed for an unqualified 1.0 but you do not expect to see fixed in RC1.

Remember RC1 has not been released yet and so there is still time to get more bugs fixed; maybe RC1 can be an unqualified 1.0.

#17 Is calling it RC1 a big and unnecessary PR risk?

by ralphmellor

Saturday March 30th, 2002 8:15 AM

Reply to this message

> Why do you say that it is clear that RC1 will not be > nearly good enough to be renamed as the unqualified 1.0?

On reflection, that's unwarranted.

Let me see if I can nail down my concern without overstating anything. It would be OK if "Mozilla 1.0 Release Candidate 1" had a minor regression or two, but it could well be rather bad news press-wise if it includes any significant regressions. My guess would be that the press would lambast Mozilla for having such poor QA practices that they A) have not bothered with the conventional alpha/beta sequence, and B) have, consequently, released a buggy product. *I* know that this is wrong, that Mozilla has had milestones instead, and that it will be adopting conventional alpha/beta nomenclature post 1.0, but that's beside the point. So, I'd like to see a "Mozilla 1.0 Beta" even if it's followed just a few days later by a "Mozilla 1.0 Release Candidate 1", or even more simply by an after-the-fact dual labelling of the Beta as RC1.

-- ralph

#19 Re: Is calling it RC1 a big and unnecessary PR ris

by Tseng

Saturday March 30th, 2002 12:35 PM

Reply to this message

Who cares what the press says? Just because sites with bad reporting from Open Source outsiders like ZDNet or even worse MozillaQuest may point out bugs in RC1, that is no reason to stop the cut of a so-titled release.

#20 Re: Is calling it RC1 a big and unnecessary PR ris

by Tseng

Saturday March 30th, 2002 12:35 PM

Reply to this message

Who cares what the press says? Just because sites with bad reporting from Open Source outsiders like ZDNet or even worse MozillaQuest may point out bugs in RC1, that is no reason to stop the cut of a so-titled release.

#53 Re: Is calling it RC1 a big and unnecessary PR ris

by sacolcor

Monday April 1st, 2002 9:53 PM

Reply to this message

Hmm...but IIRC, mozilla.org declared M13 to be the first Alpha release, and 0.9.0 as the first beta.

#62 RE: Is calling it RC1 a big and unnecessary PR ri

by JoeCool <joel@sysopt.com>

Tuesday April 2nd, 2002 9:01 AM

Reply to this message

This hasn't seemed to be a problem for Microsoft.

<shrug>

#7 Is calling it RC1 a big and unnecessary PR risk?

by ralphmellor

Friday March 29th, 2002 6:16 PM

Reply to this message

From the above it appears that the current plan is to cut, within the next week or so, a branch that will be called "RC1". But it seems pretty clear that it won't really be a "Release Candidate" in the normal sense of the term, ie it won't be nearly good enough to be renamed as the unqualified 1.0. I was struck by this, and I began to reflect on what it might mean.

First, I'll note that I have jumped to the conclusion that the "release candidate" label is intended mostly to get people to take the release more seriously than might otherwise be the case. I certianly agree that it would be smart to emphasize the significance of this upcoming 1.0 cut to users/testers. I could also understand that for internal reasons, there needs to be a release candidate in the stated timeframe, even if everyone knows it probably won't cut it.

However, I think the public label "Release Candidate" will have at least as big an impact on the press as it would on users, and I wonder if this has been carefully considered. I would expect the tech press to treat it as a genuine "Release Candidate", which means that A) they will review this rather than a release a couple weeks later and B) they will argue (despite any disclaimer text Mozilla might write) that it is more representative of Mozilla's self-defined standard for quality than it really is. Unless RC1 is more stable than one can reasonably expect, this twin effect could very likely result in a lot of unnecessary negative press. Perhaps this is a good thing; there might then be another round of press once a much better RC2 or RC3 comes along. But maybe not. My point here is to ask, "has mozilla.org thought about the press coverage consequences of an inappropriate RC1 label?"

-- ralph

#11 don't release until next Friday, April 6

by morg

Friday March 29th, 2002 8:06 PM

Reply to this message

There are a whole load of bugs that we need really, really bad for 1.0. We need another week of checkins.

#18 Re: don't release until next Friday, April 6

by _rgw_ <webbs@fayette.net>

Saturday March 30th, 2002 10:15 AM

Reply to this message

I think that is the plan...I think.

#26 RC1: more on whats left for 1.0 type of bugs..

by dman84

Sunday March 31st, 2002 6:53 AM

Reply to this message

see this bug:

<http://bugzilla.mozilla.org/show_bug.cgi?id=132965>

if you can help thats good.. we need a lot of help coming around the corner..

#30 Do not release binaries of 1.0 code

by ipottinger

Monday April 1st, 2002 12:31 AM

Reply to this message

*** RELEASING BINARIES GENERATED FROM THE 1.0 CODE IS POINTLESS SINCE, BY DEFINITION, THE 1.0 CODE REQUIRES NO FURTHER TESTING.

This is assuming that prior to the release of the 1.0 code, all known and newly reported bugs would have been deemed to be either: 1) resolved by a (trivial) fix that requires no further testing of the code, or 2) not a \"show stoppers\" and hence will be tolerated within the 1.0 code. If any bug had not met one of these two conditions then, assumingly, development would have continued after which binaries of a new release candidate code would have been offered for testing and reevaluation of all new and know bugs would have begun again.

Releasing 1.0 code binaries might allow previously unknown bugs to be discovered, but to what end? The 1.0 code, by definition, is not a release candidate to be altered and retested. \"1.0\" is, however, a point in the development of code when testing is stopped and, even though known and unknown bugs might still exists, the code is released \"as is.\" With a new round of contributions, hacks and bug fixes, development of the 2.0 code will begin. Then and only then, in the 2.0 development cycle, should new binaries be released and testing begun anew.

*** MOREOVER, BINARIES OF THE 1.0 CODE ARE COUNTERPRODUCTIVE TO MOZILLA EVANGELISM.

Since, as stated above, 1.0 binaries can play no useful role in the development of the 1.0 code, their existence can only be a source of confusion that promotes the misconception that mozilla is a end-user product instead of a code base on which a end-user product can be built. This misconception leads many to evaluate the mozilla project in an inappropriate fashion, often resulting in bad press or negative word of mouth that paints the entire project in an unfavorable light. Already, too many individuals look upon mozilla.org as the producers of a browser suite especially since the publicly available test binaries (milestones) make it so obviously clear that the code is being developed and tested in that form. These same individuals go on to complain that \"the mozilla browser\" is incomplete, missing key feature found in most browser suites like spell checking, encrypted email, etc. With that in mind, a release of 1.0 code binaries could be the source of more bad press that, though unfortunate, will be understandable and, more importantly, *avoidable*.

Take, for example, the developer of the spell checker code licensed by AOL/Time Warner and combined with mozilla code to form the feature rich Netscape 6.x. If besides spell checking, this company also produces code for page-layout, printing and other word processing feature (I\'m not sure, I don\'t know who they are) then developing and testing all that code in the form of a word processor might be the must efficient and effective way to proceed. Providing their code and test builds to the public, as mozilla.org does, might bring the benieft of thousands of extra hands and eyes poking and scanning for errors along with the odd complaint from a confused few about missing features in \"the company\'s word processor.\" However, if that company announce a point-oh release of their code and then provided word-processor-like binaries of it, then they would be actively courting disaster. Since the binaries could not possible be \"test builds,\" the only possible purpose the public could assign them is the representation of the company\'s effort to produce an end-user product. The avoidable unfortunate feedback, regardless of how harsh, would be understandable.

Hopefully, mozilla.org soon will also be the producer of spell checking and email encryption code. The producers of products like Netscape 6.x will need not build or license from others as much code as they do now and mozilla.org will be increasing seen as a one-stop open source of useful code. WE CAN ENCOURAGE THAT PERCEPTION IF THE CODE AND ONLY THE CODE IS PRESENTED TO THE PUBLIC WHEN IT IS DECIDED THAT 1.0 HAS BEEN REACHED.

----- I\'ve submitted the above is the text as bug 134597 since I want to know mozilla.org\'s opinion on my arguments. Go there to vote if you agree but please post your public comments in this forum or email your private comments to <ian@pottinge.ca>. Thanks

#31 Corrected email address

by ipottinger

Monday April 1st, 2002 12:46 AM

Reply to this message

Please note that the spelling mistakes and incorrect email address (s/b <ian@pottinger.ca>) are mine. The extra spattering of annoying backslashes are mozillazime's. Hopefully, some interesting feedback will be yours. :-)

#36 Re: Do not release binaries of 1.0 code

by ibotan

Monday April 1st, 2002 10:07 AM

Reply to this message

But the release of 1.0 is *not* an end to development. To answer your question, you need to think of what 1.0 is supposed to mean. mozilla.org's definition of 1.0 was included in the the mozilla 1.0 manifesto at <http://www.mozilla.org/roadmap/mozilla-1.0.html> . 1.0 is a promise to all clients of the mozilla code that a set of api's will be frozen and not change under their feet anymore. A separate brance will created and *maintained* in order to keep this promise.

What does this mean for development? Right now, for every bug the question is being asked: is this important enough to hold 1.0 for? After 1.0 is released, that question will be changed to: is this important enough to bring over to the 1.0 branch, if we do can we still keep our promises of stability, and is this problem even relevant to the branch? If the answer is yes, then changes will be made to the branch. Sooner or later the branch will be frozen again and 1.01 will be released.

As you can see, testing will not stop. Binaries for 1.0 are just as important as any other milestone. (If not moreso.) The enhancements you've listed such as a spellchecker will almost certainly not make 1.0, but that doesn't mean they are necessarily excluded from a later branch release. The spellchecker in particular currently works as an add on and should not require any of the 1.0 promises to be broken if it is included in a later release off the branch. There simply aren't enough resources at the moment to make sure it is of high enough quality to include with 1.0 itself.

The question of whether mozilla.org should be releasing binaries that are easily mistaken for end user software is completely different and a hard one. I myself am grateful for the releases that have been made and use mozilla just as I would any end user browser. In the end, this is really the only way to fully test it. Which gives us a very fine line to walk.

To say that 1.0 should not be distributed as a binary would not help the matter in the least. mozilla.org will continue to release binaries nightly and by milestone, which will soon bury the 1.0 release itself out of sight. Both trunk and milestone branch builds. Branch builds will still need to be available for testing, do you propose to hide those as well? Personally I feel that would do little good, but without doing so, not releasing a 1.0 binary will be useless as well.

#37 You're missing my point!

by ipottinger

Monday April 1st, 2002 10:40 AM

Reply to this message

It is my interpretation that mozilla.org exists to produce CODE, not binaries. It is my interpretation that mozilla.org releases binaries only for the purpose of testing the CODE.

If mozilla.org releases binaries for any other purpose than testing THE CODE then those binaries should and will be viewed as the release of a end-user application. But the CODE was not meant to represent a feature complete end-user application and therefore any binaries derived solely from that CODE can not possible meet the standards that the general end-user will expect.

Obviously some people, myself included, will find 1.0 binaries suitable for everyday use, but that is irrelevant! MOZILLA.ORG PRODUCES CODE, NOT BINARIES!

#38 Re: You're missing my point!

by zontar

Monday April 1st, 2002 11:35 AM

Reply to this message

I think proponents of this view are just making excuses. Otherwise, what's the point in writing the code in the first place?

#44 what's the point?

by ipottinger

Monday April 1st, 2002 2:19 PM

Reply to this message

To supply software houses with code on which they can build their own products!

#45 Wrong.

by grahams

Monday April 1st, 2002 2:50 PM

Reply to this message

Well, the mission statement at Mozilla.org diagrees with you. It clearly says \"We coordinate the open source Mozilla browser project. Mozilla is an open-source web browser, designed for standards-compliance, performance and portability.\".

Their product is a web browser. A corollary product to that is a codebase that is very useful to other people.

#49 Re: Wrong.

by ipottinger

Monday April 1st, 2002 5:29 PM

Reply to this message

Now this is what I've been waiting for. A well thought out arguement with facts to support it. Thanks you!

I suggest that those words be changed to relect that mozillla.org is in the business of making coding, not end-user products. I think an organization like mozilla.org and the code that it has developed are ill suited to catering the need of the general public. The linux experience highlights the fact that open source community have not yet managed to create the infastructure neccessary to support the general public. For now, like linux, mozilla is best servered when pasted through the hands of a cmmerical enitities. Netscape and AOL are in the business of providing "services." Service is their life's blood!

Why not let the service companies concentrate on service while coding organization concentrate on coding?!?

#51 Re: Re: Wrong.

by zontar

Monday April 1st, 2002 7:09 PM

Reply to this message

So what's your true motivation for wanting to see Mozilla's mission changed, which you only admitted to after someone called you on the fact? Coding doesn't take place in a vacuum. Are you worried that somebody's not going to make money from it?

#54 you sure?

by niner

Monday April 1st, 2002 11:34 PM

Reply to this message

If open source is not suited for general public, how can it be, that some open source projects have the simply most user friendly ways of achieving things (like installing software) you can imagine?

#79 Not that I disagree entirely, but....

by FrodoB

Thursday April 4th, 2002 1:37 PM

Reply to this message

The easiest way to install software has been and continues to be on the MacOS, where many programs (including the likes of Office) can be installed merely by being dragged to a folder on the hard drive.

#80 Re: Re: Wrong.

by Ugg

Friday April 5th, 2002 4:26 PM

Reply to this message

1 - Please calm the fuck down. Your doomsday prophet-style ranting isn't helping anything.

2 - You're creating problems where none exist. If anyone downloads a piece of software that's clearly marked for testing purposes believing it to be intended for use as end-user software, then surely that's their problem.. and if they happen to be journalists, and report on the software from the standpoint of believing that it is end-user software, then they're being poor journalists.. and poor journalism certainly didn't start with Mozilla, no will it end with it. Life goes on.

As far as nitpicking moz.org's mission to death, why do it? Only an intellectual moron (which I must necessarily conclude that you are), or a lawyer (which is sort of the same thing), would misinterpret the existing mission statement, or so desperately need to re-engineer it to the point of being mind-numbingly specific. I suggest that you root around in your closet and find where you left your common sense.. and when you find it, let the guys on Bugzilla know that your bug can be marked "invalid". Thanks.

#39 Re: You're missing my point!

by ibotan

Monday April 1st, 2002 12:06 PM

Reply to this message

My point was that mozilla.org has a use for the binaries it produces. While the code they produce is *not* a direct end user product, it needs to be tested as if it were. They will only grow a large enough external testing community to do this by producing binaries.

But besides that, you are only arguing that binaries not be released for 1.0. What good does that do if binaries are available for all other versions of the code produced? (Especially nightlies.) As I said, work will still be done on the 1.0 branch after it is released, so there\'s a need to be able to test that branch. Since a large mozilla QA community exists outside of Netscape, that means these binaries must be publicly available.

Besides, how do you argue that mozilla code could *never* meet the standards an end user expects? Yes, Netscape has some whiz-bangs they add to mozilla before they create a release. But most of the rest of the work they do is QA of the codebase. (Most of which *is* relevant to improving the base code of mozilla itself.) Is the open source of Mozilla much more polished because of this, I believe so. Does it continue to move in the correct direction? Yes. Is a Mozilla release different from a Netscape release? Yes. And the end users who would rather have IM than a QA menu *do* still go to Netscape for their releases. Those who would rather the QA menu are the ones most likely to file bugs within bugzilla. Which was the whole purpose of creating some binaries.

Not having a spellchecker or PGP plugin at the moment does not make Mozilla any less likely to grow to meet end user expectations. Mozilla is not perfect yet, but it is still growing up. 1.0 is *not* the be all and end all of development. A spellchecker is only the beginning of the polish Mozilla will recieve in the coming months and years. It may not meet al the requirements now, but how much closer is it than a year ago? Where will it be a year from now? And how much of this is form the ideas and people who have been attracted to the project by having a simple binary they could download and view the promise of?

So to recap my point, I don\'t believe that Mozilla is actually seen as an end user product. The real end users are the ones who have never even *heard* the name Mozilla, but would use Netscape in a heartbeat. While there are a vocal minority who argue that Mozilla is already an end user product, refusing to produce binaries won\'t quiet them. They will look at the small tangible difference between Netscape and a compiled Mozilla and draw their conclusions from that.

#40 You're point is inconsistent.

by JBassford <jasonb@dante.com>

Monday April 1st, 2002 12:41 PM

Reply to this message

Even if I believed that Mozilla is most definitely not an end user product (which I don't - I've posted previously against this), it would still be inconsistent to want to withhold the binaries for 1.0 but to supply them for other builds, especially nightlies.

Either ALL binaries should be withdrawn, or the 1.0 binary should be offered. Unless there's some other reason for excluding ONLY the 1.0 binary that I'm missing here.

#43 Inconsistent?

by ipottinger

Monday April 1st, 2002 2:16 PM

Reply to this message

Binaries are released ONLY for the purpose of TESTING the code!

#47 Re: Inconsistent?

by mick129

Monday April 1st, 2002 3:36 PM

Reply to this message

and so 1.0 should be released so we can test it before 1.0.1 comes out.

#48 Re: Re: Inconsistent?

by ipottinger

Monday April 1st, 2002 5:12 PM

Reply to this message

The only changes to the code after testing the final release candidate binaries will be limited to "(trivial) fixes that requires no further testing of the code." So what is there to test.

Testing is done in the final release candidate! 1.0 code HAS BEEN TESTED and had been deemed ready for release!!!

#50 Re: Re: Re: Inconsistent?

by djm <djm@mindrot.org>

Monday April 1st, 2002 6:05 PM

Reply to this message

You are still labouring under the misassumption that Mozilla is not an end-user product.

Mozilla is the default browser on most Linux distributions. The lack of email encryption and a spell checker doesn\\\'t make Mozilla any less useful as a _browser_ anyway.

#55 dman84

by dman84

Tuesday April 2nd, 2002 5:01 AM

Reply to this message

well he hasn't gone to the mozilla.org site and looked at the roadmap that explains the 1.0 branch release he's thinking of.. and the trunk which goes to 2.0.. there is a big differences.. and yet.. binaries are release so we can test the code so it gets better so we can release it to other distributors.. hello?!?!? What part of this doesn't make sence..

#56 I cant believe I put my name on the title..

by dman84

Tuesday April 2nd, 2002 5:03 AM

Reply to this message

I do dumb things like that after I get home from working all night and come back and work with mozilla...before I go to bed to do it all over again tomorrow..

#52 ever hear of a 1.0.1? (NT)

by joschi

Monday April 1st, 2002 7:10 PM

Reply to this message

(NT)

#82 Testing = Using

by TheK <kl@3dots.de>

Sunday April 7th, 2002 9:06 AM

Reply to this message

The only way to really test the code is to use it in a daily way. If you only ran Mozilla over some test pages, you wouldn't see problems. This sounds like "banana software", but it is't - the code has been tested before and will be tested any further. The 1.0 release only says "ok, here's a stable codebase on which features you can depend on and do whatever you want with - build your own app upon it or even use it as it is, if you don't need more.

#59 He has a point, folks

by JoeCool <joel@sysopt.com>

Tuesday April 2nd, 2002 8:40 AM

Reply to this message

What he has done is point out that there is a degree of hypocrisy amongst the mozilla.org \\\"administration.\\\" They (I believe I hear Asa most commonly) have adamantly, time-and-time-again told us that mozilla was just to develop for Netscape (and to a lesser extent, the world), and if you want to use a browser intended for end-user use, use Netscape. That\\\'s why they have no intention of removing the Debug and QA menus and prepare the browser for mass public consumption.

I must say that I almost agree with him. People ARE going to use mozilla 1.0 as the final Heaven-sent browser it is, and they ARE going to judge it in every way even if it wasn\\\'t intended to for true end-user consumption. I would agree that the admins need to pick their route right now. If it really is not for end-users, then this should be a zero fan-fare release (and indeed, perhaps even without a binary). And if it is for end-users, then be do a few more of the little things that users will expect from their browser... because that\\\'s mozilla 1.0 will be: their browser (and mine).

It\\\'s time to put up or shut up. And personally, I\\\'d prefer the latter.

#60 OT: mozillazine slashes

by JoeCool <joel@sysopt.com>

Tuesday April 2nd, 2002 8:48 AM

Reply to this message

Are these ever going to be taken care of in the code? It\\\'s not like it\\\'s hard to delay the introduction of addslashes into a post until it has been approved for submission (login correct). This bug has been around for ages (I can remember back for a year and a half at least)... why can\\\'t it just be fixed and be done with it? sheeesh

#61 lol

by JoeCool <joel@sysopt.com>

Tuesday April 2nd, 2002 8:49 AM

Reply to this message

(and I can't even get my password right 2 times in a row. I suck)

:)

#66 Re: OT: mozillazine slashes

by shin

Tuesday April 2nd, 2002 3:21 PM

Reply to this message

Because you're not expected to enter backslashes yourself. Blame not the program for thinking it would addslashes() every post before putting it in the database. :)

#67 I like binaries

by shin

Tuesday April 2nd, 2002 3:25 PM

Reply to this message

Even though I'm slightly more advanced than Joe-the-n00b users, I won't fancy a "./configure | make | make install" to install Mozilla every other day if I can just use an installer.

Also 1.0 introduces an API freeze (if I have read correctly for some months), and _that_ is something to make noise about !

#69 Re: He has a point, folks

by asa <asa@mozilla.org>

Tuesday April 2nd, 2002 8:27 PM

Reply to this message

"They (I believe I hear Asa most commonly) have adamantly, time-and-time-again told us that mozilla was just to develop for Netscape (and to a lesser extent, the world)..."

I've neaver said that Mozilla was just to develop Netscape. Please don't put words in my mouth. I've said that mozilla.org provides binaries for testing and development purposes. There is nothing inconsistent there. We've said that from the first day we started making binaries available. Testing helps us make the code better so that Beonex, Netscape, OEOne, IBM, Sun, HP, etc. can more easily build and distribute great products to end users.

"If it really is not for end-users, then this should be a zero fan-fare release (and indeed, perhaps even without a binary)."

I've proposeded the binary only release in the past, but changed my mind. There is far too much value in the testing feedback that we get from every Milestone to give that up, especially as we start the long-lived stable development 1.0 branch, off of which many, many products will be based. The 1.0 branch beyond the 1.0 Milestone must continue to improve and 1.0 feedback (bug reports and talkback crash data) will help that in a big way.

There is also little sense in not capitalizing on the oportunity to announce broadly the stabilization of certain APIs, the overall stability of the codebase and the usefulness of the application and application platform to hopefully induce a broad range of companies and organizations to take another look at this codebase. Fan-fare is something we need. We've got a great technology and when people discover this we should see many more distributions, derivatives and other Mozilla-based applications springing up.

I've never said that there weren't people using it as an end user product. I use it as my exclusive browser and mail client. I've said that we don't intend it as an end-user product and will not support it as such. I also use other "in development" products like nightly snapshots of the Ximian desktop, the Nautilus file browser and beta releases from several non-OSS vendors. They all have "end user" problems and I report some of those problems so that future versions will get better. I'm not a traditional enduser, that isn't traditional end use.

--Asa

#72 couldn't of said that better myself..

by dman84

Wednesday April 3rd, 2002 8:24 PM

Reply to this message

I totally agree with Asa's point..

Since people need something to read to understand about RC1 and Moz1.0 and you seem to have to keep telling new people.. so Asa, how about framing in on the Mozilla site? Is there a new web pages coming online soon or are they still being developed?

Still seeing bugs regress even now.. but more argh.. I can believe this is broke now stuff...

-dman84

#73 I meant framing your last comment...

by dman84

Wednesday April 3rd, 2002 8:32 PM

Reply to this message

geez.. I really need to proof read my comments, I guess I think of time constraints and post fast so people will see it soon.. or that I'm so busy that I dont have time to proofread that I hope will understand what it is I'm saying.. its because my brain is much faster than my typing abilities. So I'm thinking of something in the general sense and type in something vague and notice after I hit submit that I forget details.. So by the time I start typing in what I wanna say, my brain is already thinking of something else, or something related.. so hopefully when you read it you put the two things together to see what I'm saying.

does that make sense? hehe ;)

#81 Re: Do not release binaries of 1.0 code

by jensend <jensend@iname.com>

Saturday April 6th, 2002 8:09 AM

Reply to this message

I think everyone got taken in. Did anyone see the posting date on this thing? The discussion has raged on, but the user who started it posted only on April 1st. The bug submission date for the "do not release binaries of 1.0 code" is March 31st at 23:21 which means that it was April 1st according to the majority of the world and probably where this person resides. His posts in that discussion were all on April Fools' Day as well.

#33 uh...

by sl8r

Monday April 1st, 2002 1:39 AM

Reply to this message

Did lancer move to canada?

#58 Re: Re: Wrong.

by zontar

Tuesday April 2nd, 2002 8:39 AM

Reply to this message

There *does* appear to be a View Source issue with regard to dynamically-generated pages. Server dynamism, I mean... try viewing source with 0.9.9 on a page built from some DB queries and you get back HTML riddled with things like server-generated "such-and-such variable not defined" errors. It's weird. I have to switch to NS4 or (*shudder*) MSIE sometimes when I'm debugging PHP pages in order to see what the generated HTML is actually looking like.

#63 Re: Re: Re: Wrong.

by bzbarsky

Tuesday April 2nd, 2002 9:54 AM

Reply to this message

This got fixed yesterday and there was much rejoicing.

#65 I can't believe what I just read

by shin

Tuesday April 2nd, 2002 3:14 PM

Reply to this message

Do you mean the most voted bug got RESOLVED FIXED ?

... I'm breathless :D It will be just so easier to debug PHP and such now !

michel v

#71 Re: I can't believe what I just read

by bzbarsky

Wednesday April 3rd, 2002 2:19 PM

Reply to this message

Yep. Quite right. :)

#68 Re: Re: Wrong.

by zontar

Tuesday April 2nd, 2002 4:09 PM

Reply to this message

Sprite flowed freely... ;-)

#74 Netscape released 6.22 based on .99 ...

by baffoni

Wednesday April 3rd, 2002 9:00 PM

Reply to this message

Just a little something different for those who are tired of talking about the relative merits of RC1, it looks like Netscape decided to do a warmup to the release based on 1.0 ....

#75 Re: Netscape released 6.22 based on .99 ...

by asa <asa@mozilla.org>

Wednesday April 3rd, 2002 9:59 PM

Reply to this message

Netscape certainly did not do a 6.2.2 based on 0.9.9. Your information is wrong

#76 My goof?

by baffoni

Thursday April 4th, 2002 7:44 AM

Reply to this message

I pulled this off of the about information: Gecko/20020314 Netscape6/6.2.2., I just figured because .99 has this (Gecko/20020311) they were off of the same code, but you are saying that they are on different branches, but the same (or close to it) codes?

#77 My Goof, prt 2

by baffoni

Thursday April 4th, 2002 7:53 AM

Reply to this message

I hope you are right about 6.2.2 not being off of the .99 branch - I was a little worried when I didn't see the mail search bar (IMHO one of the best new features of the current code)! It would be nice if they put some sort of branch designation in their gecko ID code to minimize the confusion (like Gecko.95/20020303 or some such).

#78 Re: My goof?

by AlexBishop <alex@mozillazine.org>

Thursday April 4th, 2002 12:25 PM

Reply to this message

The Gecko build date is just the date that the Gecko code was pulled from the tree. It's not related to the actual date that the code is from.

Alex