Subject: M14 plans: Netscape's effort to produce a commercial alpha/beta
Date: 02/07/2000
Author: Jim A. Roskind
Newsgroup: netscape.public.mozilla.seamonkey
Where is this schedule going for Netscape?
As I've mentioned in previous status commentaries, Netscape staff is hoping to be able to
use the M14 checkpoint as a basis of a commercial beta or alpha. Our
hope is that we'll be able to take a series of bi-monthly checkpoints M14, M16, etc. as
progressively better baselines for pre-releases (Netscape will typically provide additional
QA, and very very very selective additions to a checkpoint, to construct a Netscape
branded release). Eventually, after some TBD number of such beta's, we hope to
produce an actual FCS (First Customer Ship) of a full blown Netscape branded
production release. To make that plan a reality Netscape is driving its in-house
contributors to Mozilla to focus on M14.
We currently believe that by M16 Mozilla will probably be pretty feature
complete. We're also hoping that M16 will be a point at which most if not all public
interfaces will stop evolving. In addition to any of our near term goals, you'll also
see effort to supports Mozilla's target in the M16 freeze
How does M14 tie in? What are Netscape's near-term priorities when contributing to
Mozilla?
Netscape's first step is to itemize some number of bugs that our marketing
department selects as "beta stoppers." We've begun marking such bugs with the
"beta1" in the keywords field, and getting the PDT (Product Delivery Team, which
includes marketing) to approve the nominations. Approvals are made by marking
the status whiteboard with "PDT+." Those two tags, when searched for
simultaneously, provide a list of what Netscape feels are initial beta-stoppers.
Inside Netscape we're pushing our engineering team to add an extra level of focus on
driving down this bug count, so that M14 has a *shot* at
being the basis of a Netscape branded pre-release. (We're still giving an even higher
priority for Dogfood/PDT+ bugs, but that is a clear need for the Mozilla codebase in
general).
If M14 has relatively few Netscape "beta1" PDT+ bugs, then what will
happen?
Assuming the M14 checkpoint (scheduled to freeze for stabilization on 2/15) has
relatively few beta stoppers (something under 100), then we'll probably try to help
resolve most of the stoppers during the M14 freeze. Just as we did in the
Dogfood thrust (re: M12 release in December), we'll try to restrict checkins during the
freeze to significant regressions, and to beta1/dogfood stoppers. We expect that
after about a week or two of stabilization, we'll be down to the point where few engineers
are still able to contribute to the "constrained" M14 development. At that point
(number of beta1 stoppers will be very low, probably under 20, and possibly around 10),
we'll branch for finalizing M14. The trunk will then open in some format for
continued work towards M15 and M16, while the M14 branch gets its final
adjustments. The M14 branch will probably get worked on for less than a week
before an M14 final is tagged (put on the wire). At that point, while most
development goes forward on the trunk, Netscape will continue to "qualify" a
continuation of the M14 branch as a basis of a commercial release. We haven't
figured out if we'll "branch from M14," or continue on the M14 branch... but that is small
potatoes and TBD. Eventually Netscape's will decide "enough is enough" and the
resulting "M14 plus a few fixes" will get a Netscape branded blessing.
That last paragraph is all about the "happy ending" or "happy beginning" of getting the
Netscape distribution system going and releasing branded versions of Mozilla.
Inside Netscape, we're all pushing for that "happy" story... but we're also watchful of the
"less happy story." The "less happy story" starts with:
What will happen if at M14 freeze, there are still a ton of beta1 stoppers?
If on 2/15, we still see too many beta stoppers to reasonably drive an M14 derivative to a
commercial release, then we shoot for an M15 based Netscape branded
release. Netscape staff would help Mozilla quickly into and out of a brief M14
freeze/branch/ship (just like a typical checkpoint, as was done with M13).
I won't dwell on this "less happy" option, as I don't want it to happen. I want to get the
world psyched about this Mozilla project being real. I believe that to tell the world
that this browser/mailer free source effort is _real_,
we need to get commercial vendors to release derivatives of the Mozilla tree, and I think
that Netscape will probably be the first such distributor. The sooner that happens
the better. The sooner that happens, the easier it will be to get additional
contributors. The sooner we get a commercial release, the sooner we'll have an
FCS. :-).
What can I do to help get a (Netscape) commercial beta version of Mozilla out
sooner?
For the many contributors to Mozilla, there are a variety of talents and contributions that
could be applied to help our effort. First off, if you have any PDT+ bugs, and
you can nail them sooner than later, that would be a big help. Next, if you
already have some bugs that have been nominated to PDT+, and claim to have been
fixed, but you know otherwise, please chime into the bug report asap. If
you know of some bugs that you think are beta stoppers (example: all too common crash
scenarios? embarrassing user experiences? terrible performance when
compared to Navigator 4.x?), then please nominate the bug by adding only the
"beta1" keyword to the bug (only the PDT gets to do approval... sorry). Such
nominations with approval will attract resources from across Netscape to resolve the
issue before M14 goes out.
Can we really get the codebase in shape by M14 to achieve this milestone?
The road won't be easy. We are currently sitting at around 300 PDT+
(approved) bugs, and it is only a bit over a week till our 2/15 freeze. The good
news is that I've watched our bug kill rates in the past, and we regularly achieve a net of
200 or better net resolutions in a week. I've seen kill rates as high as 300+ in a
week. Better yet, many of the "beta stoppers" are actually crashers, and
menu polish bugs, which are often not that difficult to resolve. The bad news is that
there are some hard bugs, but I said the road wouldn't be easy. The real question
is: Can the Netscape staff get focused on these bugs, and work to vanquish
them? Will other Mozilla contributors think that this plan and quest are worth
joining, and pull with us?
IF the answer to those last questions is yes, then I'm sure we can achieve this milestone
as part of the M14 checkpoint. I know a lot of staff at Netscape that is shooting for that
target, and I'm hopeful that others will join us.
Thanks for listening, and thanks in advance for any and all help in our quest,
Jim
---
Opinions expressed are mine, and not Netscape's