Mozilla development roadmap

Brendan Eich

Welcome to the Mozilla development roadmap. This document briefly describes where the Mozilla project has been, and then details where it is going. It proposes key "road rules" and a release schedule for ongoing Mozilla-the-browser source milestone releases, from which anyone can build commercial and other products. It also hints at how Mozilla-the-platform should evolve, again from an operational or "release process" point of view.

background

The original roadmap recorded the momentous decision in October 1998 to reset the Mozilla project around the new layout engine (now called Gecko), a cross-platform front end (XPFE; now several XP Apps built on an XP Toolkit), and a scriptable components architecture (XPCOM and XPConnect).

The previous roadmap charted Mozilla's path through the release of Netscape 6 and beyond, toward the goal of releasing a Mozilla 1.0 milestone. In that update, I wrote "Mozilla needs performance, stability, and correctness" and not any particular new feature. Just before 2001 began, I wrote that useful and relevant (defined by the community) extensions are always welcome, provided that they don't have a high opportunity cost in terms of contributors who otherwise could and would have helped hack on 1.0. But by the fall of 2001, as noted in the Mozilla 1.0 manifesto, the opportunity costs of features and extensions had grown to the point where such "non-1.0" work jeopardized a 1.0 milestone that fit into any achievable schedule.

This roadmap update reflects the milestone schedule for the summer of 2002, now that Mozilla 1.0 has been released.

tree management

Here is a depiction of the latest thinking on tree management:

In a departure from the five-week milestone cycle of 2001, each major milestone takes one quarter of a year or thirteen weeks to be delivered, and starts with a five-week "alpha" milestone, during which destabilizing development should be done. This is followed by a five-week "beta" milestone period during which less risky bug fixes, in particular followup and cleanup of the alpha phase work that tend to restabilize the codebase, should be targeted. Finally, a two to three week "done" period, where only driver-approved changes can be checked in, completes the milestone. There is enough slack to allow a floating holiday week per quarter, which we hope will help avoid the "time and people shortage" experienced last December, during 0.9.8.

Each milestone ends with a release to gather automatic crash reports ("talkback"). We believe that this feedback must be gathered and acted upon at least every five or six weeks, based on our several years' experience. We hope that alpha and beta milestones need no more than a few days' tree closure to prepare for release. As we do not intend to promote alpha and beta releases for uses other than testing, we will ship those releases according to the predetermined schedule, and let the chips fall where they may. Again, the once-per-quarter major release (e.g., 1.1) is the product-worthy branch-point.

Thus we hope to match the rhythm of the Mozilla community, which seems to have resulted in an odd-even pattern of "alpha-ness" and "beta-ness" observed since at least 0.9.1, along with a protracted freeze and branch effort before enough bugs were wrung out to release.

Finally, we are rationalizing our release numbering to count branches, with the leading 1 for the trunk version. Thus the 1.0.1 branch-of-a-branch sketched in the picture above, although at a date yet to be determined. The long-lived 1.0 branch should host conservative development of bug fixes that may also be appropriate for the trunk, per the Mozilla 1.0 manifesto's rationale,

Interested parties should collaborate, with support from drivers@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.

Tabulating the milestones to show the proposed dates, with trunk freeze, branch creation, and milestone release dates distinguished from one another (the next milestone's start date is the previous one's branch date), yields:

milestone start freeze branch ideal release actual release
1.1alpha 09-Apr-2002 05-Jun-2002 n/a 07-Jun-2002 11-Jun-2002
1.1beta 07-Jun-2002 10-Jul-2002 n/a 12-July-2002 22-July-2002
1.1 12-Jul-2002 31-Jul-2002 02-Aug-2002 09-Aug-2002 ?
1.2alpha 02-August-2002 04-Sept-2002 n/a 06-Sept-2002 ?
1.2beta 06-Sept-2002 09-Oct-2002 n/a 11-Oct-2002 ?
1.2 11-Oct-2002 30-Oct-2002 01-Nov-2002 08-Nov-2002 ?
1.3alpha 01-Nov-2002 04-Dec-2002 n/a 06-Dec-2002 ?
1.3beta 06-Dec-2002 08-Jan-2003 n/a 10-Jan-2003 ?
1.3 10-Jan-2003 29-Jan-2003 31-Jan-2003 07-Feb-2003 ?
1.4alpha 31-Jan-2003 05-Mar-2003 n/a 07-Mar-2003 ?

Traditionally, the milestone freeze time is 12 A.M. Pacific Time (see the tinderbox page for notices) on a Wednesday (that means midnight Tuesday to most people). During the freeze, only bugs deemed "must-fix-for-this-milestone", typically last minute regressions, are fixed on the trunk, as everyone tries to qualify the daily builds as branch-worthy. Release staff@mozilla.org create the milestone branch, which receives even more intensive QA over the weekend, leading to a release at the earliest by the following Wednesday.

We have tried, and sometimes failed, to avoid slipping any release, to avoid extending the life of a milestone branch and dividing labor poorly between trunk and branch. In spite of past difficulties, we aim to release by the Wednesday following the freeze, and use the "done" mini-milestone to absorb extra work that might cause an earlier slip. So, any not-quite-showstopper bugs unfixed by Wednesday should be targeted at the next Mozilla milestone and fixed ASAP.

Drivers have proposed these changes to the previous milestone plan in order to use "even more obvious" milestone numbers, to match the odd/even stability pattern and end-game schedule observed since 0.9.1, and to match calendar seasons and business quarters (with only a week's skew from the vernal equinox to when the 1.1alpha trunk should open). If you are planning a Mozilla-based product release whose schedule does not jibe well with the above milestones, we welcome your feedback (we will keep confidential information to ourselves, and will sign NDAs if necessary).

how you can help

Mozilla embedders: we need your input to Bugzilla, marking bugs with embed, footprint, mlk, perf, mozilla1.0.1, mozilla1.1, and other relevant keywords. Mozilla project management will help ensure that bugs are assigned to hackers who can target their fixes so as to satisfy as many milestone-keyword nominations as possible.

Bug assignees, and especially helpers who can offload Futured or untargeted bugs from their nominal assignees and fix those bugs: please make a pass at targeting your assigned bugs across the mozilla1.1 and mozilla1.2 milestones, using the criteria in the Mozilla 1.0 manifesto. Please try to offload bugs to helpers, pinging drivers@mozilla.org if you cannot find anyone to help fix futured or untargeted bugs that you believe should be fixed soon.

Community members: please use the mozilla1.x milestone-keyword nomination system wisely, and do not change the Target Milestone of anyone else's bug without the assignee's consent. The keyword-proposal/target-milestone-disposal system will continue beyond 1.0 to help inform prioritization by bug assignees. You may of course vote for bugs also to help inform prioritization (but remember that patching beats voting; also, please keep advocacy out of the bug system).

code review

mozilla.org is continuing to require code review across the board to approve checkins to the bulk of the Mozilla codebase. The Mozilla Code Reviewers document distinguishes areas of code that require this so-called "super-review" from those hosted on cvs.mozilla.org that have other policies set by module owners. All code hosted by mozilla.org requires active ownership, and therefore module owner review of changes before a contributor can type 'cvs commit'.

Design review obviously should precede code review! Use the porkjockeys mailing list (which has a news gateway) to raise design questions and issues.

project management

To drive developers looking to help toward bugs needing assistance in a timely fashion, to moderate risk, and to aid commercial projects based on Mozilla in managing their product releases, mozilla.org has created a group of project managers, drivers@mozilla.org.

The current drivers are:

I hope, in the not too distant future, to update the roadmap with some thoughts on the future of the Mozilla project after 1.0. Clearly, bug fixes, architectural changes, and new code waved off from mozilla1.0 will want to land during 1.1alpha. Mozilla also needs to support the "Mozilla-the-platform" side of the coin for more applications than the default-built browser/mailnews/editor/chatzilla suite. I hope too that Mozilla technologies and innovators can make significant qualitative improvements (e.g., via something like Intertwingle) in how we all browse, organize, and cope with information on the web, in our file systems, and locked into application data formats, wherever such data may live. There is life after 1.0 -- stay tuned!

Copyright © 1998-2002 The Mozilla Organization.
Last modified August 1, 2002.