Good doc. couple of comment.
Because of the way we do statisical analysis on the crash bugs from talkback
report we will always have "topcrash" bugs as long as anyone continues to
report any crashes at all. Bug stats show:
topcrash fixes-last 30 days: 48 bugs found.
total crash fixes-last 30 days: 135 bugs found.
I've crashed once since starting to use the 0.9.1 bits several weeks ago,
and reported MTBF for many of the folks sending in talkback reports
is execeeding 100 hours. Having said all this I think there are about
1 or 2 major milestone releases to go before we can gather the talkback data
needed, analyze it, fix the bugs and re-release to confirm the fixes.
If we kept up the focus on this and made this happen I think we be pretty
close to being able to make the claim that we had the most stable
brower ever produced, with few to no reproducable crashers that
are encountered by any significant number of users.
I think that would statisfy the mozilla 1.0 criteria ;-)
[EMAIL PROTECTED] is going to be working their tail off
for the next month to provide the data needed to get us there
and we are counting on support from lots of engineers to be
applying another one or two rounds of crash fixes to the trunk
and 0.9.2 branch. We can use lots of help from every mozilla
follower and contributor to file talkback reports and provide detailed
comment that tell what you were doing and if the bug is reproducable.
Yes, lets do the same thing for data loss bugs.
On the request to cls for info on the build system I know of a couple of
things.
With the performance team landing of the static build enabling branch that
gets a good deal of the heavy lifting out of the way for some major build
system work. Getting it turned on will be more tweeking over the next
couple of weeks. The preformance gains provide by static linking should
be a requirement for 1.0.
Another major build reorg effort will be to set up the build system to
do a more effecient job of producing components for embedding applications.
This is going to be a good sized effort and cls, mcafee and others will
start
to get there hands around this monkey in the next month or so and we should
start to see progress. This one is a buy-by-the-yard feature for
Mozilla 1.0.
We will take all the progress that can get made but we may be tweeking and
improving this for a year to come. The changes will have no visable impact
to users or developers of the XUL based mozilla browser, just developers
who want to build different combinations of selected sets of individual
components.
Seawood may have more on the build topics.
Yes, lets get feedback on layout and standards compliance, make a list,
and drive the list to zero!
Yes, lets get busy outlining the tasks and then
wrap all this work up by the end of the summer and call it mozilla 1.0!
I think we are pretty dang close.
chris h.
Gervase Markham wrote:
>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
>
