mozillaZineheader image

Towards Mozilla 1.0

by GERVASE MARKHAM |

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 here , 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 missed.

There will always be unfixed bugs. This is reality. Therefore, Mozilla 1.0 will be released with known bugs we'd like to have fixed. Having clear definitions will reduce the amount of slippage.

We also need to note that, when 0.9.2 branches, a great deal of Netscape engineering resource is going to be concentrated on the branch. We will obviously get the benefit of this on the trunk, but it means that (as happened last time round) things will slow down somewhat.

Voting

I 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 Freeze

It'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.

Why? Recently, we have been going through a stable period, and people are generally pleased with the levels of stability and performance Mozilla has reached. Work continues, as it always does, and is an incremental process. We have had big jumps, like Hyatt's style landing, but in general these
three issues are a case of chipping away at a block. My point is that we should be happy with current levels - i.e. just make sure things don't get worse. Given what is below, no "crash landing" period is anticipated before 1.0, so there should be no opportunity for major regressions in these areas.

I know jrgm can produce stats about how Mozilla's performance is improving, but any line drawn on those graphs as "acceptable for 1.0" would be, to a greater or lesser extent, arbitrary. Saying we will have no official targets is not the same as saying we will not do any work in this area, of course. I fully expect work to continue, and for Mozilla to improve. It's just that because meaningful targets (as opposed to hard targets) are hard to define, this has to be assessed on gut feeling.

We could make an exception for topcrashes, but the problem is that, because of the way the data is defined, there will always be topcrashes, it's just they will become less frequent. It would be possible to produce a crash metric based on Talkback MTBF (mean time before fail) data. However, the problem with this is that Talkback only measures times between crashes; so, if the user never crashes, we don't hear about it. Also, many users change their Mozilla too often to have more than a single crash. Lastly, any figure we produce will be arbitrary anyway. chofmann says: "trying to control all the variables in a MTBF experiement is a difficult
task."

On the dataloss front, we might use a form of statement by which to judge if a "dataloss bug" is a 1.0-stopper. Something like "will cause the user to irretreivably lose irreproducible data when they would not expect such loss" or something like that.

Composer

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

Mail/News

It has been suggested that 100% GNKSA (Good Net-Keeping Software Award) compliance would be good. The meta-bug is here . This may require some help.

Architecture

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.

This is very wooly, and could do with fleshing out from some porkjockeys :-) It would be nice to know if there are any key APIs which are still undergoing serious change.

Standards Support

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
severity "normal" or above. The last three columns are subsets of the first.


# bugs futured untargetted targetted post-1.0
html4 35 14 7 3
dom0 109 68 9 1
dom1 64 32 13 1
css1 122 64 21 2

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 bug 87428 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?)

We also need to know, for each area, whether shipping with no known bugs in 1.0 is anything like feasible. Are we going to have to turn off support for certain features which still don't work? Are we going to have to say "We still don't support X"?

Features

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 exceptions are:

MathML

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.

Hyatt has tagged all the bugs he thinks should be fixed before XBL can be declared 1.0.

Build system cleanup

cls says:
I opened up a bug a few months back about build changes that I wanted to get in before 1.0.

There are some minor build only issues:

  • standard unix install:: target
  • selectively building components
  • making the default build for end-users/developers

as well major build issues that involve the entire tree:

  • setting soversions on components (implies API freeze)
  • the static build work.

Here are some issues not mentioned in the bug:

  • single pass build
  • removing the use of SHARED_LIBRARY_LIBS
  • documenting this beast (yes, I said the D word)

Optimistic ETA is the end of August. Realistic ETA is a bit further out :-)

UI Tidyup

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

Accessibility

The accessibility web page 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

Chart of which languages are most represented on the Net. Figures reproduced as text below. 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.

We need to start collecting commitments to produce langpacks for 1.0. I think we should aim, at the minimum, to have a langpack for each language explicitly named in this pie chart (sourced here ), i.e.

Language % of Net users Last known langpack NS 6.01
English 47.5 0.9.1 Y
Chinese Simplified 9.0 0.8
Chinese Traditional 0.9.1

Japanese 8.6 0.9.1 Y
German 6.1 0.9.1 Y
Spanish 4.5 0.6 Y
Korean 4.4 0.8
French 3.7 0.9.1 in progress
Italian 3.1 0.9.1 Y
Portugese 2.5 M14/M17
Russian 2.1 0.8.1

(The Portugese page contains a commitment to translate for 1.0.)

This would reach 91.5% of internet users directly. Of the remaining users, I think most will speak one of the languages on that list. After all, everyone speaks English, right? ;-) Any other packs are a bonus.

Can someone comment on which l10n packs Netscape plans to officially support (and which are therefore pretty much guaranteed to happen)?

Timeframe

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.

Hopefully the results of the discussion which should follow will give us some idea of what that timeframe should be.

Documentation

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.

Modularisation

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.

4xp

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


Let the discussion begin :-)

Gerv

Got a response? TalkBack!

Home

MozillaZine and the MozillaZine Logo Copyright © 2000 Chris Nelson. All Rights Reserved.