Here's the context we are using to evaluate scheduling of milestones:

1) We are driven by quality, not time.  We want to Firefox 3 to be
something that we are all proud of.  This means features that delight
users and the same or higher quality than previous releases.  "Quality"
includes performance (Tp/Ts/TDHTML/etc), footprint, web compatibility,
regressions, and general fit and finish.  Having said that, we want to
move the web forward and are in a competitive market.  So we should
converge on a release as fast as possible.

2) There has been almost 2 years of development on the 1.9 platform
incorporating major changes: Reflow, Cairo, Cycle Collector, Native Mac
Widgets, contenteditable, many parts of the Web Apps 1.0 Spec, etc.  We
need to have enough "bake time", public milestones, and regression fix
time to ensure we meet our quality goal.  We should also endeavor to get
this functionality into the hands of users and web developers as soon as
possible.  The sooner we ship this the sooner web authors can count on
 >15% of their users supporting the latest capabilities and standards.

3) The Firefox front-end has had significantly less development time
than the platform and has yet to have the opportunity to innovate on top
of infrastructure built for places, password manager, and others.  So
we'd like to give them until M8 to continue to develop user-visible
features on top of the core infrastructure.

4) A milestone schedule with a release every 6 weeks (4 weeks till code
freeze from last milestone, 2 weeks of stabilization/build work) seems
to work the best.  Note that actual tree closures will in practice
likely be shorter than 2 weeks if there are not multiple re-spins.

Based on this context the proposed schedule is:

* M7: Freeze on July 25
        * Platform feature freeze
        * This is the "web developer preview release" since it is    
        platform complete.  This will be marketed at a higher volume
        than other alphas to help get wider-scale testing.
* M8: Freeze on Sept 5
        * Firefox feature freeze
* M9: Freeze on Oct 16
* M*: Ongoing as needed

Feature Freeze = all planned features are implemented and exposed
(through APIs and user interface elements) in ways that are usable, but
not necessarily polished. After freeze, landings will be restricted to
regressions (from 1.8), performance and footprint fixes, as well as
additional functional or unit test coverage and changes to APIs and user
interface elements based on feedback from the beta cycle.

In order to hit our goals above we are going to do the following:

1) Only explicitly named platform features are available for landing
before M7 (with exceptions heard by the release drivers).   At the time
of this writing the only platform features remaining to land before M7
that I'm aware of are Anti-malware, Secure wrappers, and some Offline
work.  This means if you are working on a platform feature for 1.9
that's not on this list you should help close out the long blocker list.

2) The trunk will go under release driver control after M7.   This means
all check-ins will require release driver approval after July 25.
Release drivers currently include MConnor, CBeard, Betlzner, Basil,
Schrep, Damon, Vlad.  Additional volunteers welcomed :-).  As always
these folks will do frequent triage and will rely heavily on the
judgment and assistance of module owners and experts in each major
functional area.

3) We'll switch from Alphas to Betas as soon as we believe Firefox is
stable and usable enough for daily browsing for a large number of
people.  Until we hit this criteria we'll continue to release Alphas on
the 6 week cadence above.  Criteria:
        a) Footprint at or below that of 1.8.  This is being measured regularly
through Talos working set size (http://tinyurl.com/252ka3) and through
informal dogfooding.
        b) Most sites should display properly and regression free (from
previous major release)
        c) No known common dataloss bugs
        d) No common hangs or crashes
        e) No problems with major features in common use cases

        "Common" is defined as usage of the browser with any popular websites
or frequent occurrence in daily browsing for our dogfood or beta
population.  We'll measure this through frequency of bug reports and
direct feedback from users.

        Based on this criteria it does not appear that M7 will be ready to be
called a beta.  Talos is showing a ~18% increase in Footprint and
informal dogfooding confirms things are currently worse on the trunk.
Search for keyword mlk in bugzilla to find plenty of known bugs here.

4) We'll release betas until we complete our regression work and
incorporate feedback from wider-scale testing.  Before we release the
final beta Performance (specifically Ts, Tp, Tdhtml, Txul, and any other
benchmarks we add to the main tinderboxes) will be as good or better
than 1.8.  We should strive for improved Tp and Tdhtml scores
performance v.s. 1.8.

5) After the last beta we'll release a Release Candidate.  The Release
Candidate is meant to be bit-for-bit the final release.  Only new
problems found after the RC is released will cause additional RC's to be
published.  Once we are confident there are no new issues we'll release
the final release.

So in summary:

* Can I land platform feature or old bug fix X?
        * In general no, but read above carefully
* When will Beta 1 Ship?
        * As soon as it is ready (see #3 above)
* When is the next Milestone?
        * 6 weeks from the last one.
* When will the last Beta ship?
        * As soon as it is ready (see #4 above)
* What can I do to help?
        * Platform folks let's sprint to the finish.  Footprint, performance,
regressions, unit tests! Everyone involved wants to get a beta into
people's hands asap.  We could also use your help getting the blocker
lists managed.  If it doesn’t fit that criteria please minus it.
        * Firefox - you've got a little bit of time left to crank. Delight us!
        * Everyone else - plenty of help needed reproducing, filing, and
confirming bugs.  Dogfood.  Run the nightly tester tools + leak gauge,
help us hammer this thing into shape.