[LWN Logo] 

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