Towards Mozilla 1.0
This is version 2.0 of a short, unofficial document aimed at starting a discussion to define more clearly the requirements for Mozilla 1.0. It has been revised based on the first round of feedback in the newsgroup . Please read that before commenting there.
[ Note: please do *not* comment to this article with a list of your favourite "my 1.0-stoppers" bugs. This will only create noise. We are looking for bug selection criteria, not bug numbers themselves. ]
The current Mozilla 1.0 definition document can be found
, but is only a rough draft and hasn't really been updated since it was
written at the end of January. I intend to do a quick survey of the issues
outlined there; people should raise other issues they feel that document has
VotingI think that votes for non-enhancement bugs should be taken into account when deciding what bugs to fix for Mozilla 1.0, but this should not be an absolute criterion. The main reason for this is that it's not usually the people voting who are doing the work :-) Anyone can vote, including people who "just think it's cool" without realising how much effort fixing the bug or implementing will actually be, and people can open multiple Bugzilla accounts to vote for their favourite bugs (and would, if we had a "fix all bugs with more than X votes" policy.) For example, Print Preview has 23 votes, but it's not going to be in Mozilla 1.0, because there's no-one with the cycles to implement it. (It's not an "enhancement" because it was in Netscape 4.x .)
Feature FreezeIt's becoming more and more clear to me that we need a feature freeze, or at least a slush. This is partly to prevent destabilisation of the tree, but more importantly to concentrate people on the bugs in the stuff we already have. If contributors are encouraged by mozilla.org to concentrate on bugfixing, and people know that if they implement new features they are less likely to find reviewing and super-reviewing cycles, and will get asked hard questions at super-review and approval time, this can only be a good thing.
Footprint, Performance and Stability
I want to start by making a controversial statement: we should have no,
or very little criteria in these categories for Mozilla 1.0.
Haven't heard anything from the Composer team yet, and I don't know anything
myself. I'm not sure if the CSS-isation of Composer is planned for a 1.0
It has been suggested that 100% GNKSA (Good Net-Keeping Software Award)
compliance would be good. The meta-bug is
. This may require some help.
All the key APIs should be frozen. This definitely includes all APIs, like
Plugins and OJI, likely to be written to by third parties. There's a document
somewhere which gives the status of a large number of our APIs, but I can't
for the life of me find it. This should clear things up a lot.
We should stick to what we promised - world-beating support for DOM0, DOM1,
HTML4 and CSS1. Here are some stats, showing number of open bugs at
dbaron says: "We're doing pretty well with CSS1 and DOM1, although there
are some significant (although not huge) issues left, such as gamma correction
(this also affects the images) and block vertical margins in CSS1 and null-ness
of strings in DOM1. There are also a bunch of minor issues. HTML4 is a whole
other story. My understanding of what was promised and what people will
expect is that we have "full support" for HTML4, not just conformance. If
we want full HTML4 support, we need to push hard to get things like
and bug 6782
This is a key area where a 1.0 buglist needs to be made ASAP by our standards
gurus. For each of the above areas, we need a nominated "the buck stops
here" person who makes the final decision on a per-bug basis. (I assume
this would normally be the module owner.) It would be very good to see cycles
officially dedicated to the task of creating this list, and for each module
to publish either the list or a Bugzilla query capable of making it (all
bugs targetted at 1.0 or before?)
Almost all of the features listed in the 1.0 document have now been checked
in. This is good, because it implies that the tree will not need to go through
another unstable "fiery landings" period between now and Mozilla 1.0. The
We are waiting for fonts to be sorted; without decent Math fonts we can
ship, MathML support is a bit pointless. A company which has consented to
supply them and has produced what seems very much (to me) like a compatible
license for them. We need to work out how to integrate them into the build
and ship and install the cross-platform. The MathML code itself has been in
the tree for a while; however I believe it still requires super-review to
be turned on by default.
XUL Cleanup for XUL 1.0
There's one checkin pending, and Blake says he personally isn't doing any more of the dependencies on the meta bug . There are only a couple there which look like Mozilla 1.0 stoppers to my untrained eye. It would be good to hear the plans of the rest of the XPToolkit team in this area.
all the bugs he thinks should be fixed before XBL can be declared 1.0.
Build system cleanup
as well major build issues that involve the entire tree:
Here are some issues not mentioned in the bug:
Optimistic ETA is the end of August. Realistic ETA is a bit further out
UI TidyupWe need to get our UI in a usable state. Currently, reasonably large bits of it are not as desired. This means deciding who exactly is going to produce the specs, and producing them. It means the buck stopping with one person, who I think would be Ben Goodger.
The accessibility web
hasn't been updated recently. The Accessibility branch landed in mid-May,
which implies the remaining work is bug-fixing and interoperability tests
with accessibility clients. Is that right?
I18n / L10n
Mozilla.org will need its own i18n UI text freeze. It would be good to get
input from l10n groups on what sort of lead time they need to have language
packs ready for simultaneous release. There are currently 58 different l10n
groups, however only 14 of those have produced a pack targetted at 0.8.1
or later. Major languages like Korean, Portuguese and Spanish all have really
out of date langpacks.
(The Portugese page contains a commitment to translate for 1.0.)
Looking at all the above, I assert that we do need to define a timeframe
for 1.0. It's all very well for one module owner to say "I am going to get
my module to point X (in terms of functionality and stability) by 1.0" and
another to say "I'm aiming for point Y", but if point X is due to be reached
in July, and point Y in November, that doesn't get us very far. This is
not an abandonment of "it's ready when it's ready", but more a recognition
that expecting everyone to converge on the same point without some idea
of where it will be is reasonably unlikely.
Mozilla is an extremely large and complex application with a high barrier to entry for new engineers (particularly those outside Netscape.) Having each engineer spending a week doing a brain dump of stuff they know about their area would go a long way towards lowering that barrier, and increasing everyone's productivity. I think we should consider constructing some minimum documentation level standard and enforcing it across the tree. This will only be good for everyone in the long run.
It has long been a goal of mozilla.org's to get the Mozilla codebase into a state where each component could develop independently and you could pull and build the "latest stable" release of each component to make a stable browser. This can only happen when APIs freeze. I would therefore suggest that this reorganisation be the key priority in the immediate post-1.0 period.
4xpDo we need criteria about which bugs must be fixed if they weren't in 4.x? The problem with this is that 4.x did some things badly (this is particularly relevant to UI bugs) and did some things we perhaps don't want to do.
Got a response? TalkBack!