You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Mozilla 1.0 manifesto

Brendan Eich

What

People often ask "Why should Mozilla have a 1.0? Why not just keep going and let vendors pick good milestones retrospectively?" There are several reasons to do a 1.0, enumerated below. But let's agree on what a "Mozilla 1.0" would be:
  • The first major-revision-number milestone release (Mozilla 1.0) of the Mozilla browser application suite and platform from mozilla.org. A release of higher quality than any delivered so far, on whose quality our reputation is at stake precisely because 1.0 is such a coveted and feared version number.
  • 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.
  • A stable, long-lived branch off of the cvs.mozilla.org trunk (MOZILLA_1_0_BRANCH). Interested parties should collaborate, with support from staff@mozilla.org, in developing conservative fixes for critical bugs in this branch. Anyone who wants a baseline for development that will work with the public APIs of Mozilla 1.0 is free to develop against the 1.0 branch.

Why

Mozilla consumers, including many companies developing products, need a stable, long-lived branch with these properties:

  • API compatibility commitments (for example, the frozen embedding APIs).
  • Library version identification (so at least vendors can know when to require an upgrade, or to bundle a new rev to replace a downrev .dll or .so file).
  • Enough modularity that important core modules (e.g., XPCOM) can stand alone.
  • Stability -- acceptable MTBF, no serious dataloss bugs.
  • Good performance and memory footprint.
  • Better-than-any-competition standards compliance.
  • Usability, correctness, polish (not too many non-crash bugs and misfeatures).
This need is acute: if mozilla.org does not create such a branch to share or to branch from for individual companies and organizations, various consumers of the code will do it themselves, with less information sharing, coordinated effort, and consequent quality than we would like.

We think the world will be a better place, with more hands helping to improve Mozilla, and more people benefiting from distributions of Mozilla, if mozilla.org hosts a consolidated, stable, and long-lived branch, along with the active, ongoing development of the trunk. This branch obviously entails overhead in driving, merging, reviewing, and testing. We're not sure exactly how it will be managed (what its roadmap will be), yet -- but we see the need, we want to have a plan, and we welcome your input.

A note on the 1.0 branch: It's conceivable that non-conservative changes could take place on the 1.0 branch, so long as they are "additive". But we would much prefer that the bulk of the active developers keep hacking on the trunk, and take advantage of binary compatibility of frozen interfaces to deliver modules built from trunk sources that work with any 1.x milestone.

How

This stable, long-lived, branded branch cannot happen without concerted effort to fix certain bugs. We need to identify the bugs and drive the buglist to near-zero. To do that, without being utterly date-driven, we need to pick a small number of milestones during which we ask developers to schedule fixes for their Mozilla 1.0 bugs. Of course, contributors have different ideas about what constitutes a Mozilla 1.0 bug. Some people believe that most standards-compliance bugs should be fixed for anything that deserves the 1.0 brand. That's ok, but the number of milestones needed to fix such a long list is hard to guess, but probably quite large at the current fix rate.

This is a call to all Mozilla developers: if you believe, as we do, that the world needs a "1.0" from mozilla.org soon, then please concentrate your efforts on the dependencies of bug 103705, the Mozilla 1.0 tracking bug.

Given the constraints identified above, we still have a short-term requirement for a stable, relatively long-lived (a year minimum, at a guess) branch. However we brand this release and branch, 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). So we are asking people to schedule their most important Mozilla 1.0 bugfixes over the four milestones starting with 0.9.6, through 0.9.9.

As we've said often, we're not looking for new features; we want stability, performance, best-available standards compliance, tolerably few bugs, and good APIs.

Features cost us time directly (opportunity costs born by those implementing the features, who likely could instead help fix 1.0 bugs) and indirectly (collateral costs on code reviewers, expert consultants, and other helpers). If you think you must have a feature by 1.0, please be prepared to say why to drivers, and be prepared to hear "we can't support work on that feature until after 1.0 has branched" in reply.

If, as seems likely, commercial contributors must have features implemented in the milestones before 1.0 branches, we may wish to isolate those features to CVS branches, or via #ifdefs. We may trade features for fixes to let in a very few exceptions that have been proven to be innocuous. But we won't get a short-term "1.0" done if we don't take a hard line, and we ask all our contributors to join us in holding that line.

When

The majority of staff and drivers surveyed believes that the "1.0" brand should be used sooner rather than later to identify our stable, long-lived branch with API commitments. We believe "sooner" means within the next six months, based on feedback from various vendors, book authors, and others in need of such a branch.

We contend that a milestone where only fixes for topcrash and other severe bugs (e.g., dataloss) get checked in, with lots of regression testing and code review, is necessary before we can confidently brand a Mozilla 1.0. The 1.0 milestone period is therefore likely to be one during which the tree is closed to all but driver-approved changes.

All of this taken together suggests that we have at most 0.9.6 through 0.9.9 to get to a Mozilla 1.0 milestone during which the trunk is closed to all but a relative few bug fixes, and everyone is focused on testing. There's obviously a lot of work to do to get to that milestone, and more to be said about how to organize the work, but I'll leave that for an update to this document. Your feedback is welcome.

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.

Who

We need help from all of you who have bugs linked to the Mozilla 1.0 tracking bug. (But please, don't spam the bug, change its dependencies, or otherwise put your bugzilla access at risk! Use the newsgroups for discussion.) This list is not yet complete. It will be fleshed out in consultation with key people in the various areas, and with your feedback, in the coming days.

Final say for what goes into 1.0 must come down to one person, whom for better or worse is me -- but there are layers of people to whom I delegate, and whose judgment and consensus I trust, in order to do the right thing. First in the line of delegation, judgment, and consensus are staff and drivers, who in turn depend on porkjockeys, reviewers, module owners, bug assignees, QA contacts, triagers, and other members of the community. We are now identifying owners for the dependencies of bug 103705, which are currently (and temporarily) assigned to nobody@mozilla.org. If you want to help by owning one of these tracking bugs, please mail me.

If you believe a bug should be fixed by 1.0, nominate it by setting the mozilla1.0 keyword. The bug may be assigned and targeted at 1.0 or a nearer milestone. If drivers and the relevant 1.0 tracking bug owner believe the bug is important to 1.0, it should be linked as a dependency. Feel free to propose the bug if it is not linked, targeted, or even assigned yet, but please ask yourself:

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

Mozilla 1.0 dependencies:

  • APIs
    • XUL 1.0
    • XBL 1.0
    • XPCOM
    • Embedding
    • Plugins
    • DOM (which bindings beyond JS?)
    • String ? (needed by DOM if we freeze the DOM C++ bindings)
  • Modularity
    • Building components standalone
      • XPCOM
      • JS (build system)
      • XPConnect
      • Necko ?
    • Fixing bad dependencies (extensions should not be required)
      • wallet
      • cookie
    • Extensions cleanup
  • Packaging, versioning
    • DLL versioning
    • ABI manifest (supported platform x toolchain list)
  • Standards
    • Future compatibility problems (e.g. lack of uniform gamma correction among PNG, CSS, etc.).
    • Widely used standards that web authors depend upon
  • Stability
    • topcrash
    • dataloss
    • upward MTBF trend, all-time maximum
    • talkback on Mac
  • Usability
    • Every UI element does something useful (query for the useless-ui keyword).
    • No missing or clipped UI elements (no resizable dialogs).
    • No dead ends, whence you cannot return.
  • Performance
    • startup
    • page load
    • new window
    • UI response
  • Footprint
    • code
      • Remove deadwood (e.g., viewmanager2).
      • Avoid virtual methods and XPCOM costs where not needed.
      • Specific reductions.
    • data
      • Reduce steady state footprint, exclusive of leaks.
      • Fix leaks.
  • Security and Privacy
  • Correctness
    • Anything obviously and badly broken that doesn't fall into one of the above categories.
  • Polish
    • spelling
    • visual glitches that don't break usability
    • anything ugly, but not impossible to work with, and fixable soon
  • Default configuration features
    • MathML
    • DOM Inspector
    • Venkman
  • Party