This is a short, unofficial document aimed at starting a discussion to
define more clearly the requirements for Mozilla 1.0.
Everything contained herein is my opinion only, and things stated as facts
may in fact be downright incorrect. Discussion will be in the newsgroup
netscape.public.mozilla.seamonkey. This message has been cross-posted to
groups whose input is requested.
[ Note: please do *not* reply to this message 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 definition document can be found at
http://www.mozilla.org/roadmap/mozilla-1.0.html , 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.
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. We can't compare to
4.x - because we do so much more. We can't compare to NS 6.0, because it
sucked, perf-wise :-) We can't compare to IE, because it doesn't run on
all the platforms Mozilla does.
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.
The one exception to this is in the case of topcrashes. In this case, I
think we should (nearer the time) name a cutoff date, such that "all bugs
reported before this date and then assessed to be topcrashes will be fixed
for Mozilla 1.0." This doesn't stop us fixing big crashes after that date,
it just puts a sensible lid on things. There will always be unfixed bugs.
Hmm... do we also need to do something similar with dataloss bugs?
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 future untarg post1.0
html4 35 14 7 3
dom0 109 68 9 1
dom1 64 32 13 1
css1 122 64 21 2
It would be good to get input, even of the touchy-feely sort, from the
NGLayout people on how close we are, and how close we can get in the next
week/month/quarter. Do the above numbers represent a crisis, or a steady
progression towards something acceptable? When will we get there?
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 arranged; without decent Math fonts we can
ship, MathML support is a bit pointless. This is in the hands of Frank
Hecker and [EMAIL PROTECTED] This _should_ be quite close to being
resolved; the company which has consented to supply them has produced what
seems very much (to me) like a compatible license for them. The 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
http://bugzilla.mozilla.org/show_bug.cgi?id=70753 . 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.
Is there any XBL syntax cleanup necessary? I know XBL has headed over to
the W3C as a proposed standard of some sort, so it must be pretty nailed
down.
Build system cleanup:
I mailed cls about this and he hasn't replied. It was only 24 hours ago;
this is due to my impatience, not his tardiness. But it would be good to
know if there are major build system changes we need to make before 1.0.
Accessibility:
http://access-mozilla.sourceforge.net 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.
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 on:
http://www.glreach.com/globstats/chart.gif
(that's from http://www.glreach.com/globstats/ ), i.e.
Lang % 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.
Modularisation and Documentation
--------------------------------
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, and some _serious_ documentation work by
everyone, be the two key priorities in the immediate post-1.0 period.
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.
Let the discussion begin :-)
Gerv
