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:

Why

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

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:

Mozilla 1.0 dependencies: