Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Mozilla The Internet

The Mozilla 1.0 Definition 279

The Evil Beaver writes: "Here we go. Mozillazine is reporting that Brenden Eich, mozilla.org's Technical Bigshot, has released the criteria to what is to be the 1.0 milestone. The 'manifesto' also explains why 1.0 is so important to reach, and why it isn't just another milestone, either. The Mozillazine article is here and the definition document here.
This discussion has been archived. No new comments can be posted.

The Mozilla 1.0 Definition

Comments Filter:
  • But.... (Score:4, Funny)

    by sheriff_p ( 138609 ) on Wednesday October 17, 2001 @08:34AM (#2440695)
    Where's the "World Domination" item?
  • by Hektor_Troy ( 262592 ) on Wednesday October 17, 2001 @08:42AM (#2440721)
    Could it be, that what we're seeing isn't the infamous slashdot-effect, but in fact a conspiracy preventing anyone not using the latest build of Mozilla on the latest build of the linux-kernel from entering the page?
  • by onion2k ( 203094 ) on Wednesday October 17, 2001 @08:42AM (#2440724) Homepage
    Better-than-any-competition standards compliance

    There in lies a bit of an issue. The standards aren't done yet. Nor will they be. Standards are an evolving thing. The big issue of the Netscape/IE wars in the late 90s was that both parties tried to predict where the standards were going, and tried to go straight to the final standard without waiting for them to be ratified.

    And they both failed.

    We had 'non-complient' browsers, different object models, different CSS models, IE and NS specific tags.. it was a right old mess. Trying to be 'most standards complient' implies an attempt to out-do the other browsers, which is precisely where NS particularly, and to a degree IE, fell down. It gave everyone a right old headache.

    The problems arise when the web designers find a new feature they happen to like a bit (CSS colour control of scroll bars being a current example), that doesn't work in all browsers, and theres a great big shift toward the browser that does the 'coolest' things.

    Yes, be standards complient. Be 100% standards complient hopefully. But just remember that it has nothing to do with how complient the others are.

    • by StupidKatz ( 467476 ) on Wednesday October 17, 2001 @08:56AM (#2440774)
      Here's the REAL issue: "Standards are an evolving thing." They *shouldn't* be, and true standards do not evolve much, if at all.

      Imagine if a kilogram was 2.2lb one day, then 4.3lb the next. Not much of a "standard", is it?

      The major browsers were all "compliant" with ... HTML 1.0 and such base stuff, but web designers are trying to make the WWW do things it was never designed to do, and *that* is where this horrible mess of Javascript kiddies, broken CSS, and browser specific "features" came from. I don't know about you, but I'd rather not see all that flashy crap on a web site. Web sites need to contain *content*, not eye candy. :P
      • by onion2k ( 203094 ) on Wednesday October 17, 2001 @09:08AM (#2440822) Homepage
        Not quite what I meant. HTML 'standard' is set by the W3C, but it evolves. Its currently at 4.3 (I think). So does the Moz team work toward that? After all, by the time they're done it might be at 4.7. This is the trap into which NS and IE fell. They tried to code for a standard that they hoped would be *the* standard by the time they shipped. Both missed the target. But had they written for what was at the time the current standard they'd have been releasing browser that, while stable and complient, would have been miles behind the competition in terms of features. Which is why writing a standards complient browser should be undertaken by someone who isn't trying to make money. Delibrately being behind your competition would be suicidal.

        As for the content of web sites, I'm still a 'content is king' web master. As are many of us. But when we probably aren't the web surfing majority. People want flashy gimmicks and toys on sites. And more and more web 'designers' are all too willing to give it to them.
        • Current W3C recommendation for HTML is 4.01 (which is 4.0 with bugfixes)
        • Actually the current HTML spec is XHTML 1.0 Revision 2 [w3.org] released last week.
          • Actually the current HTML spec is XHTML 1.0 Revision 2 [w3.org] released last week.

            And just why do you exclude XHTML 1.1?

            It's actually very unclear which version of (X)HTML is the current "HTML recommendation". If it's not XHTML 1.1 then I can't really tell from the W3C documents which one it is.

            Of course XHTML 1.1 is quite unusable in today's browsers, but that's another matter. You can't really (fully) use even HTML 2 in them...

        • by hiroko ( 110942 ) <david.balch@co@uk> on Wednesday October 17, 2001 @09:48AM (#2440953) Homepage
          The current and last version of HTML is 4.01 [w3.org]. HTML is no longer being developed, having been superceeded by XHTML [w3.org], based upon XML [w3.org]. These are (two of) the standards mozilla team is working to, and future standards will build upon them.

          Moz does use its own extensions to the standards, and features of draft standards, but has implemented them in a manner that states them clearly as mozilla (a "moz-" prefix I think).
          These extensions are not being encouraged as "wow look at this great feature" but developed to fulfill needs such as assisting the themes capability, or because a developer is particularly interested in it. The advance work is not enabled in all builds, but will give an advantage when the standard is reccommended (complete).

          The point of mozillas approach to standards is to get the existing standards working fully and correctly, anything else is a bonus.

          (skipping moderation duty to comment :)

        • They tried to code for a standard that they hoped would be *the* standard by the time they shipped. Both missed the target. But had they written for what was at the time the current standard they'd have been releasing browser that, while stable and complient, would have been miles behind the competition in terms of features. Which is why writing a standards complient browser should be undertaken by someone who isn't trying to make money. Delibrately being behind your competition would be suicidal.

          Both these companies tried to strongarm the W3C into accepting their versions of standards by going ahead and implementing them anyway. This began with Netscape and it's "time to market" fiasco where they felt major versions of their software had to be released at "Internet time" which lead to them forcing such travesties as Javascript, Javascript CSS and a number of other nonsensities on the web users while not fixing basic aspects of their implementation of the HTML spec like rendering tables.

          Thankfully, it seems that now the major browsers have realized the errors of their ways and no longer see "time to market" as being more important than standards compliance. The Mozilla team has been doing excellent works with regards to implementing a number of the W3C standards and Microsoft has now gone as far as to start deprecating some of their own technologies in favor of the W3C versions (e.g. XDR -> XML Schema and XSL -> XSLT).
          • Thankfully, it seems that now the major browsers have realized the errors of their ways

            The "major browser" is internet explorer. They don't worry about time to market because there's no need to out-feature the competition...because there is none. I wouldn't be too thankful for that.
        • People want flashy gimmicks and toys on sites

          Say's who? The only flashy toys and gimmicks are those obnoxious "flash" ads... It's amazing how much more I enjoy surfing without Flash installed. *aaahhhhhh*

          The only people who want that crap are the marketing drones who think it helps them get "clicks"...
      • >>Imagine if a kilogram was 2.2lb one day, then 4.3lb the next. Not much of a "standard", is it?

        That's not the "standards evolution" that happens here. It's about new functionality and methods of providing it being ratified, upgrades to existing standards such as CSS, not changing what CSS does, just expanding it's repertoire. Hence the Standard Model, to borrow from the world of Physics, keeps getting larger, so a browser needs to support more features to comply with *all* the standards.

        Now they only want to be the most standards compliant browser out there, but what happens if a "feature" of another brower model suddenly gets ratified as the best way of doing things, and that "standard" gets updated to reflect this?

        Standards compliance is a worthy cause, but, ultimately, a lost one. They need to sit down, pick the standards they want to use as they stand *now* and make it comply with those.
        Any newer standards can be included in version 1.1 or something.

        Chris.
      • I really hate it when people try tp put things in a simple little box. The web is so much more than just "content." Thats like saying the linux kernel shouldn't end up in watches or in other devices because that wasn't what it was originally designed to do.

        Don't be so close minded. The web is a constantly changing organism and I don't think there is any real appropriate definition. You can't label something that is constantly changing.

        And I assure you there is much more to the web than just text. Art, music, games, and yes eye candy all exist on the web.

        I for one am glad that they do.
      • "They *shouldn't* be, and true standards do not evolve much, if at all.

        "Imagine if a kilogram was 2.2lb one day, then 4.3lb the next. Not much of a "standard", is it?"

        Of course, the "standard" of the kilogram evolves too. As posted on Slashdot six weeks ago [slashdot.org], NIST is seeking an electronic kilogram [nist.gov] rather than a hunk of metal.

        Saying something changed doesn't indicate if it got better or worse. Merely that it is different. I think the purpose of a standard is to enable people to know that if they want to accomplish X, following steps 1, 2, . . . n will do that. But if they want to do Y or if there is a better way to do X, the standard needs to change. The point of having standards is to do other things. If all you care about is the standard, you can just use tautologies: "A light year is the distance traveled by light in a year."

        • "A light year is the distance traveled by light in a year."

          That's not really a tautology, it's a definition.

          The tautology is to then use that definition to attempt to define the original.

          "Light travels one light-year in a year."

          Is a tautology.

          The only reason it's not really clear is that "Light Year" is a phrase which is pretty straight forward and doesn't need a lot of explaning so the definition sounds a bit redundant and circular.
    • The standards aren't done yet. Nor will they be. Standards are an evolving thing. The big issue of the Netscape/IE wars in the late 90s was that both parties tried to predict where the standards were going, and tried to go straight to the final standard without waiting for them to be ratified.


      Actually that's mostly not true. The engineers from MS (predominantly but also the NS ones) were part of the forum which defined the standards (CSS1 in particular). They went back to their home companies and implemented something different.


      Yes, standards evolve, just like software. But where a standard exists, it should be followed - when you're defining software behaviour, you should follow all ratified standards up until that point.


      Adding stuff on top (with the intent of influencing standards) is OK, as long as the core is followed, and you recognise that your new stuff may be in conflict with future standards, and at that point, will have to be deprecated.


      If there is a ratified standard for a feature, you should follow the standard or not implement the feature.

      • by HamNRye ( 20218 ) on Wednesday October 17, 2001 @01:48PM (#2442257) Homepage
        (Our scene opens in a conference room at the W3C standards meetings. Reps from Microsoft (Ms) and Netscape (NS) are in attendance.)

        Ms Guy: We ned colored scrollbars in the standard.

        NS Guy: But we need themes... We don't force folks to use our boring scrollbars.

        Ms Guy: Yeah, but we force 90% of the world to use boring scrollbars, it should be in the standard.

        NS Guy: Jerk.

        Ms Guy: Hey, like it or not, IE 5.5 will support colored scrollbars, and you'll implement them eventually because you have to, standard or not.

        NS Guy: Like hell.... We still haven't implemented the marquee tag. Or page transitions.

        Ms Guy: Wow, people actually use your piece of crap???

        NS Guy: Look here Monopoly boy, if you've ever read Slashdot you know these people want to be reading ASCII in Lynx. You can tempt them with your "eye-candy" and "formatting", but if it ain't Courier New, it just plain blew.

        Ms Guy: Yeah, whatever, Nutscrape. Aren't you glad we don't make IE for Linux?

        _END_

        The sad fact of it is that Microsoft can and will set the standards for a while now. It didn't occur to me until 2 days ago that colored scrollbars are not supported. Not that it makes that big of a deal, but it can help the look of your pages if you use alot of inline frames.

        Microsoft already sets the font standards. (Because it's what you can expect to be on the client machine)

        Netscape has to go out and do everything MS can do, and then some. Linux has to do everything Windows can do and then some.

        When MSIE 1.0 came out.... But they caught up. Then they did everything Netscape could do, then they did more.

        P.S. Mozilla still takes too damn long to load up.

        ~Hammy
        http://www.nothing4sale.org
    • IE and Netscape got into trouble by trying to do an end-run around standards altogether. Features included in the 3.x series of both browsers were simply not part of any standards proposal.
  • Promesing (Score:3, Insightful)

    by TheMMaster ( 527904 ) <hpNO@SPAMtmm.cx> on Wednesday October 17, 2001 @08:43AM (#2440730)
    "* A set of promises to keep compatibility with various APIs, broadly construed (XUL 1.0 is an API), until a 2.0 or higher-numbered major release. All milestone releases and trunk development between 1.0 and 2.0 will preserve frozen interface compatibility. Mozilla 1.0 is a greenlight to hackers, corporations, and book authors to get busy building atop this stable base set of APIs."

    I must say that I find this a very "mature" perspective and this is clearly showing that the people of mozilla know what they are doing and how they should do it!
    Mozilla for world-domination (using mozilla since 0.6 BOY did THAT suck!!)
  • by collar ( 34531 ) on Wednesday October 17, 2001 @08:45AM (#2440736)
    People have been complaining about the time that it has taken mozilla to reach version 1.0, but from a developers point of view finally stamping "1.0" on the thing is a very hard thing to do. You cant say "oh that will be fixed in the next version" and "that feature is coming soon". Well, you can (and do) but people dont tend to respect you as much...

    I'm glad that they have been taking the time to get 1.0 to standard necessary, for some reason AOL saw fit to release netscape 6.0 when they did, which I think was a huge mistake. Lets be glad that the mozilla folks are not so keen to release a product before it is ready.
  • by MosesJones ( 55544 ) on Wednesday October 17, 2001 @08:45AM (#2440741) Homepage
    * Is fixing this bug vital to web content developers, Mozilla distributors, Gecko embedders, or others who will depend on 1.0 for stable code and a minimal set of frozen APIs?
    * Is there no alternative to fixing the bug that frees people to work on other 1.0 bugs?
    * What goes wrong if we don't fix the bug, and just live with it for 1.0?
    * What do we give up from 1.0 in exchange for fixing the bug?
    * Can you stare down slashdot and C|net together and at the same time, and argue credibly that the bug is a 1.0 stop-ship problem? While we are not yet at the "about to ship, why should we take any more risk" stage, this question can help us prioritize and avoid unpleasant surprises later, when 1.0 is within our grasp.



    Now that is proper requirements management, unusual in most open source projects. These are the 4 basic rules on requirements management.

    Full on for them in doing this. They are running it like a proper project and trying to control requirements creep.

    Open Source goes back into the Cathederal ?
    • Managing scope creep (Score:5, Informative)

      by aegilops ( 307943 ) on Wednesday October 17, 2001 @09:05AM (#2440807) Homepage
      I'm sure 1e5 Slashdot readers can give their two penneth in advice for project management, but suffice it to say that nailing scope for your project is a major win. Get stakeholders or key significant people to agree to what you are trying to achieve, what you include in scope, and specifically, what you exclude as out of scope.

      Then, for each product or deliverable (something you can touch, or something that now exists when it didn't before etc) that you need to produce, classify them via the acronym MoSCoW:

      Must

      Should

      Could

      Won't (i.e. not in this release)


      Helps to focus the mind on priorities. Otherwise, an excellent idea and full marks for the announcement so far.

      Aegilops

    • Now that is proper requirements management, unusual in most open source projects.

      The difference between the cathedral and the bazarre is not the presence or absence of project management. This is one of the most misguided readings of Raymond's paper, as he himself makes clear [lotus.com].

      What "The Cathedral and the Bazarre" argues (and this is frankly no great insight on Raymond's part) is that good project management doesn't require formal rules, processes, and bureaucracy. Ideally, it is based on talented leadership, shared vision, and a spirit of collaboration. This strategy is not fool-proof, of course, and is perhaps riskier than traditional management. But when it works, it demonstrably produces amazing results.

      Maybe this can't work for mozilla. It wouldn't be all that shocking, since mozilla is different from most free software projects: large, built on a traditionally proprietary codebase, run largely by a major corporation. But that's no reason to slam all the projects for which it does work.

      The two methods are always combined to a degree, of course. But they are not entirely compatible, so you can't just say "let's do both". Bureaucracy diminishes the importance of a leader, subjugates vision to process, and dampens enthusiasm. So I'll take bazaar management any day.

  • by Khazunga ( 176423 ) on Wednesday October 17, 2001 @08:45AM (#2440744)
    Mozilla is more than a browser. It's a development platform, a software layer that runs on top of a number of hardware/OS platforms, and masks the differences.

    In this light, an essential feature of Mozilla is backward compatibility between minor revisions. So, 1.0 means: "We're done with the APIs. Please come and hack away with them, we won't break your software".

  • by brunes69 ( 86786 ) <[slashdot] [at] [keirstead.org]> on Wednesday October 17, 2001 @08:46AM (#2440747)

    "Unable to connect to SQL server"

    Is this some new HTSQL standard being reffered to here? WOw, I didn't know they were working on making a XUL Query tool, thoug it wouldn't surprise me...

    :o)

  • Manifesto (Score:3, Funny)

    by Root Down ( 208740 ) on Wednesday October 17, 2001 @08:48AM (#2440752) Homepage

    ... but will the workers control the means of production?

    (The question is more important than it might initially seem.)
    • For the good of the code [mozilla.org]

      Give to the code and the code will give to you. :P

    • by ethereal ( 13958 )

      For once, entirely apropos:

      "When you program open source, you're programming COMMUNISM [mdcc.cx]."

  • Karma whoring (Score:2, Redundant)

    by Per Wigren ( 5315 )
    Go straight to the original article [mozilla.org] instead! Mozillazine seems to be down...
  • they claim to want to have the best standards compliance among compeditors. first, who are the competition? all browsers? all free (beer) browsers? all open source browsers? secondly, why such a need for the standards compliance? in the past (and still currently afaik), browsers were build on loose compliance, and extending the standards to where they see the standards going into the future (css).

    on a side note, it is good to see them put a loose timeframe on the release. their schedule has mozilla 1.0 in about 6 months, so we should expect it in about 9 realistically (sp). I can see their desire to want to lock down api's for a while on the 1.x version. We're seeing .x releases of mozilla almost every month. Won't we expect to have .x releases every month after the 1.0 release? maybe every other month?

    all i want for christmas is a one point oh, a one point oh, a one point oh... :)

    • secondly, why such a need for the standards compliance? in the past (and still currently afaik), browsers were build on loose compliance, and extending the standards to where they see the standards going into the future (css).



      Which is why we have the piece of crap system we have today. MS extensions don't work in Netscape and vice versa. I find it hard to believe that you are apparently agruing the importance to standards. It's called opening up the window of choice in operating systems and applications. When you know that any application can handle the same file formats or whatever, you have much greater flexibility in what you use to do your work, and it makes it convenient to work with others who haven't made the same choices as you.

  • I18N And L10N? (Score:3, Interesting)

    by LeftHanded ( 160472 ) on Wednesday October 17, 2001 @08:53AM (#2440768) Homepage Journal
    I didn't see any mention of internationalization (I18N) or localization (L10N) in any part of this list. Although the Mozilla site [mozilla.org] has a section for I18N [mozilla.org], L10N [mozilla.org] and BiDi [langbox.com] issues, these parts of the Mozilla site seem especially quiet. The Mozilla Team has obviously been working hard on these issues; you can tell that by the features in the latest 0.9.x releases. It just seems surprising that it wasn't mentioned in the 1.0 statement. They do want World Domination, right?
    • We'll work hard to co-ordinate with l10n teams as we near the release, so that language packs are reached simultaneously. However, bugs in the i18n area are not "come back and bite us in the butt" bugs.

      If we don't work in Thai at 1.0, we don't work in Thai. But not working in Thai at 1.0 doesn't stop us working in Thai in 1.2.

      BiDi should be in and working now.

      Gerv
    • I didn't see any mention of internationalization (I18N) or localization (L10N) in any part of this list.

      I didn't have to tell Mozilla anything or do anything special, and I can read sites in Chinese, Japanese and Korean. Check it out, here [chosun.com]'s a four-language site. I don't know how I'd go about typing CJK text though.

  • by cybaea ( 79975 ) <`moc.aeabyc' `ta' `enalla'> on Wednesday October 17, 2001 @08:58AM (#2440781) Homepage Journal

    Given the size of the dependency [mozilla.org] tree for the 1.0 milestone target [mozilla.org] it looks like 1.0 could be a little way off??

    Does anybody want to take a stab at a date? Does anyboy even want to count the number of bugs on that page? ;-)

    • Does anybody want to take a stab at a date?


      From the document:
      we need to develop a schedule that converges on a stable, useful release in at most five milestones, preferably fewer (but likely no fewer than four).

      Now, milestones tend to appear every 4 - 5 weeks, so that would be 16 - 25 weeks time (4 - 6 months)

      From the document:
      If things go well, we'll be within a milestone of 1.0 after 0.9.9. If 1.0 seems to continually recede as we approach it, our definition of 1.0 in terms of bugs to be fixed is broken. Therefore we will continually review the schedule and the outstanding bugs. If it takes an extra milestone (0.9.10), but 1.0 is reached soon enough, so be it -- but no one should count on an extra milestone. There won't be two or more extra milestones, or again, we will have failed to converge on a short-term stability branch and release within six months.

      This would seem to confirm that timescale
    • Yes, somebody has taken a stab at the date. Accodring to the manifesto [mozilla.org], we will see a few more releases (0.9.6-0.9.9) followed by 1.0 or 0.9.10 then 1.0. there will be NO other milestones. The document claims we have about half a year until the 1.0 release. This is the first firm forecast I've seen so far.

      here's the big bug holding Mozilla 1.0 back [mozilla.org]; basically a collection of extremely important bugs. Also of tremendous importance, a dependency of this bug, the Party bug [mozilla.org] ... yes, we need a party for the release!

      there is apparently more than one [mozilla.org] funny bug(here's the list) [mozilla.org] on Bugzilla [mozilla.org].
  • On a related note... (Score:4, Interesting)

    by MSBob ( 307239 ) on Wednesday October 17, 2001 @08:58AM (#2440782)
    Since Mozilla is beginning to look rather slick these days I have a quick question to someone enlightened. Is the new AOL (7.0?) interface based on Gecko or does it still use the IE control? Anybody in the know?
    • I don't know but I hope so, the sooner the "big boys" (AOL, @home...) get away from IE as a platform the better. then they can move away from MSwindows!!!!
    • 7.0 is a marketing number. It is by no means a major release. In fact, if you have 6.0 you can upgrade to 7.0 online without downloding the whole new program. Needless to say, they still use IE (which they will almost certainly always do).
  • by CptLogic ( 207776 ) on Wednesday October 17, 2001 @09:00AM (#2440789) Homepage
    >>Good performance and memory footprint.>If things go well, we'll be within a milestone of 1.0 after 0.9.9. If 1.0 seems to continually recede as we approach it, our definition of 1.0 in terms of bugs to be fixed is broken.

    What are the definitions of bugs that need to be "fixed" before a 1.0 version can be approved?

    "not too many non-crash bugs and misfeatures"

    Again, what counts as "not too many?"

    Reading this defintion document, I don't see any hard targets to hit, or even any tolerances, just a vague commitment to tighten the code already in existence and to hit moving "standards" targets.

    Judging by these criteria, I don't see how you can then stamp a *FINISHED* label to it and "ship it" as a 1.0 version.

    At some point they're just going to have to decide that an arbitrary bug fix is no longer version 0.9.10 or whatever, they're just going to have to bite the bullet and call it version 1.0

    As any filmmaker knows, "Nothing's ever finished"

    Chris.
    • I don't see how you can then stamp a *FINISHED* label to it and "ship it" as a 1.0 version.

      Who said anything about a FINISHED label? It's not like we're all going to give up and go home when 1.0 is done.

      Gerv
  • Polish? (Score:3, Funny)

    by cybaea ( 79975 ) <`moc.aeabyc' `ta' `enalla'> on Wednesday October 17, 2001 @09:07AM (#2440816) Homepage Journal

    I love Poland but is it really essential to fix the Polish language bugs [mozilla.org] for a 1.0 release? Aren't there more important priorities? Isn't 1.0 about a stable API (and product!) and such, and if so, couldn't fixing spelling mistakes in the Polish language pack wait until 1.0.1 or something?

    The document outlines some really good principles for managing software, but this entry confuses it for me. Any Polish people here to explain why it is critical? :-)

    • Re:Polish? (Score:1, Informative)

      by Anonymous Coward
      On the off-chance that you aren't kidding, and to prevent genuinely clueless people posting follow-ups, this bug is about "polish", pronounced PAW-lish, as in "buff with a cloth to add shine". Hardy har har.
  • by Odinson ( 4523 ) on Wednesday October 17, 2001 @09:08AM (#2440819) Homepage Journal
    http://bugzilla.mozilla.org/show_bug.cgi?id=100309 [mozilla.org]


    Hey, all the team needs to do is ask.

  • Yes. (Score:3, Offtopic)

    by dinotrac ( 18304 ) on Wednesday October 17, 2001 @09:08AM (#2440820) Journal
    I was so excited when Netscape opened the code.
    A long, long, time ago.

    And that's the problem. I'm not sure that Mozilla even matters any more, but I think that it does. If nothing else, Microsoft's ham-handedness with product activation, etc. may re-open the window of opportunity.

    The 1.0 approach Eich outlines is exactly what the project has needed for the last 18 months, if not two years.

    There comes a time when you stop saying "It'll be ready when it's ready" and start asking "How do we make it ready?"

    Eich's memo is the answer to that question.
    Good luck, guys.
    You can do it if you set your mind to it.
    • Oh, please. Microsoft's crappy browser has any domination on one non-Microsoft system at all (Macintosh). Who needs your "window of opportunity"? Mozilla will be used by the masses who run Unix, the ones who use it via embedded systems unknowingly, and hell -- Mozilla's going to be embedded in the AOL client, so you _know_ that if pure "market share" matters, it's going to end up having the most in the long run.

      Mozilla is stable, fast, supports a hell of a lot of important standards correctly, and doesn't suck. Say that about any other browser if you can.
      • Sure - if it's ready.

        The reality is that IE is 85% of browsers today.

        And that's what the push to 1.0 is all about.
        Making something that all of the folks who would put Mozilla in those places can use with confidence.

    • There comes a time when you stop saying "It'll be ready when it's ready" and start asking "How do we make it ready?"

      I'd say that's day 1. If you don't have a plan for getting ready, you just spend forever doing side tasks and non-important stuff. Obviously on day 1 won't be detailed, but you should evolve your plan as the project progresses.

      • I'd say that's day 1.

        You'll get no argument from me.

        I hope this whole experience teaches that there is some value to planning and prioritizing. Meeting goals isn't be a matter of saying "screw the bugs, send it out the door", even if some (too many?) treat it that way. It's a matter of saying "These are the things we can do now, those are the things we can do later."

        It still goes out "when it's ready," but you have an idea of what "when it's ready" means.
    • I do some web development, and I get clients calling our customers saying X feature isn't working on their browser. Know why? It's a buggy build of IE either on Win32 or a Mac almost all of the time. My suggestion to them is to grab the newest build of Mozilla and try it out. I can't say for certain they actually did it, but I've never gotten a complaint from a person that I told to use Mozilla again. I'm going through this right now with somebody trying to print complex HTML out on a Mac - - it's just not working. Try Netscape, if that fails, try Mozilla. I'm hoping word spreads.
  • by zerocool^ ( 112121 ) on Wednesday October 17, 2001 @09:08AM (#2440823) Homepage Journal
    At the bottom of the buglist we see Bug #100309 [mozilla.org]

    Description:
    Opened: 2001-09-18 08:55

    we need preparation as well as a good place to have the biggest & coolest party
    ever!

    that's a good bug to have

    ~z

    • That is funny (+5) they admit that the release of 1.0 [mozilla.org] is a bug.



      Also if your have the big party and thus have this blocking bug solved i think it is not wise to release 1.0 the next day.......8-)

      • That is funny (+5) they admit that the release of 1.0 [mozilla.org] is a bug.

        I think you may misunderstand Bugzilla [mozilla.org]. It's an issue-tracking system, where each issue happens to have the term "bug". So, for instance, bugs are even filed for feature requests.
    • At the bottom of the buglist we see Bug #100309 [mozilla.org]

      we need preparation as well as a good place to have the biggest & coolest party ever!

      These two Slashdot-related bugs amuse me:

      Bug #68974 [mozilla.org]

      Description:
      Mozilla 0.8 cannot be released until Slashdot is ready

      Bug #73658 [mozilla.org]

      Description:
      No Slashdot story for Mozilla 0.8.1 release

      It seems like there was another more recent one about not being able to release 0.9.something until Slashdot was ready and working properly, but i can't seem to find it... Maybe it was just the 0.8 one above.

  • Nobody can accuse them of jumping into this. It's something that they have worked toward for years now and 0.9.5 has added some great features without hurting the current level of stability. This can only be good for the project.

    Disclaimer: I use Galeon, so my main interest in Moz is Gecko to power the latest Galeon release. I do ride the lizard now and then just to see what they've done though. With the tabbed windows, they've almost caught up with Galeon. :)

    A note for fellow Slackers, Mozilla 0.9.5 [linuxmafia.org] has been up for a couple days and Galeon 0.12.4 [ufies.org] is worth snagging as well.

  • I have a question regarding a problem I've had with every release since I first downloaded 0.9.1 (Win32)*. I'm a 14m3r who relies heavily on Yahoo! Mail. But whenever I hit the "Send" button to fire off an email via Mozilla/NS6, the browser simply hangs there, doing nothing. It doesn't even have the courtesy to time out. I end up having to fire up NS 4.7 or (shudder) IE.

    I haven't been able to find anything about this on Bugzilla, even though it's something that would surely garner some notice. I'm afraid to submit it to Bugzilla myself, since it's possible that I either have some setting wrong or Yahoo! is using some non-compliant tricks that break their form. Either way, there's nothing Mozilla could do about it.

    So, is anyone else here having this problem, and 14m3 enough to admit to having a Yahoo account? More important, does anyone know why? (I've sent this question to the Yahoo people, but haven't gotten a response).

    * Sorry.
  • time to 1.0 (Score:5, Insightful)

    by RestiffBard ( 110729 ) on Wednesday October 17, 2001 @09:23AM (#2440884) Homepage
    I've been thinking about the length of time its taking to get to 1.0 and must admit that i have been critical of the dev process for Moz in the past but no more. it just occurred to me that one of the reasons that we've been so bitchy about how long its taking is the fact that development of Mozilla is taking place in the wide open. it was a daunting task when they began and it still is. there tons of closed projects that take years to get done but we never hear about them until they are done. we've been following moz from the beginning and so the whole thing seems to take longer than it should. maybe I'm just late figuring this out but i just wnated to make sure it was said.
  • by ACK!! ( 10229 ) on Wednesday October 17, 2001 @09:39AM (#2440927) Journal
    Listen I have been using Mozilla on and off since it began to be bundled with various distros.

    When it first came out I swear the pages it could render came up as fast as anything I saw from even Opera but the program loaded really slowly. In other words, when it finally came up it was really fast unless it crashed.

    Now, Mozilla can handle most any page Netscrape can handle and loads faster but the page rendering seems to be slower on regular html pages not nearly as fast as when it came out initially. I was impressed by the .94+ version I am using right now and use it for most of my work. However, I do wish the thing was quicker in rendering pages. Any thoughts on this? Is it just my perception of the program?

    • Is it just my perception of the program?

      Why don't you do a scientific test instead of going by perceptions. Download one of those early builds you are talking about, and time it loading pages. Then install the latest build, and time it again.
      • One thing that can be noted... FORM rendering is much faster now. Ever try loading a Bugzilla bug entry page on a M18 build? It was horrid. I'd shift away desktops and go back to coding for a bit while I waited. Ability to render tables quickly improvement/degredation is minimal compared to the gains done with the widgets. Extremely impressive when you consider they had to do this for OS after OS, or was it part of XUL?

        Oh, and I'm running it on Linux, dunno if the Win32, MacOS or other ports were this slow early on.
    • I've noticed the same thing. It seems as if it used to render faster (albeit, some pages were displayed incorrectly at that time, though).

      Mozilla rocks, but the thing that has kept me away from it over and over again is speed. I keep trying to 'convert' to it, but the UI speed kills me. It feels like I'm selecting menus while I'm drunk.

      I've used Galeon and that's better. I just wish that they could do somthing about the UI speed in Mozilla, though. I've read many bugs about it and at least around the 0.8 version the developers 'dismissed' the UI speed 'bugs' as platform issues. They would say: "Linux redering is inherantly slow. . .Mozilla seems fast enough for me. . .", etc.

      The UI is slow on ALL platforms that I've used. Perhaps it will never be sped up because of the inherant problem of using their own GUI toolkit which in effect is a platform issue (their platform) that will never get fixed :(.
  • We do the complete rewrite in prep for v2.0? Right?

    &lt Just kidding &gt

  • If the 1.0 release turns out to be something with rock solid stability/compliance, would it be possible that ISP's would start suggesting their customers use Mozilla, instead of IE? This would cut down on support costs associated with the bugs in IE, which i'm sure any ISP would be happy to do.
    • Regardless of the stability/compliance level, a move like that would only increase the number of phone calls to the helpdesk, at this moment in any case. Why? Many braindead websites are tested only to work with IE/NS4, or simple refuse non-IE clients. Look for Tech Evangelism bugs (there are 924 of those as I write this) for a few examples.
  • Can't really speak for the whole Lizard....But the newest Galeon has been making me very happy as of late. Version 1.0 does not have to be perfect....Keep up the good work....
  • Brendan of the Eich. Clearly a highly-ranked Boskonian.
  • Mozilla developers dilemma....

    Story on Slashdot:


    GOOD: Keep people interested in the project, debate and possibly come up with good ideas.

    BAD: They generally have a Bugzilla link, gets Slashdotted, and makes one of your primary developer tools slow to a crawl for a few hours.

  • by zachlipton ( 448206 ) on Wednesday October 17, 2001 @12:32PM (#2441804)
    I just wanted to keep everyone informed about what is happening to mozilla.org on the server side right now. Bugzilla has currently been shut down as a result of large amounts of database queries, etc, I have talked with those running the servers and this probably wont be up right away, but you never know. Mozillazine.org is also somewhat down (the sql server is dead), but a mirror of the article is availble at http://www.necrosys.net/mirrors/mozillazine-moz1.h tml. www.mozilla.org is still up and should continue to serve out Brendan's words of wisdom.

    Please stand by,
  • This is an essential feature Mozilla Mail should have - S/MIME support.
    It's a widely accepted standard for digital signatures and encryption of mail messages an PKI (Public Key Infrastructure).
  • For not inserting a snide insult after the poster's comments this time; they do get
    rather old.

1 + 1 = 3, for large values of 1.

Working...