Mike Schroepfer wrote:
> We discussed this at the last Gecko and Firefox meetings - but I wanted
> to get some notes on the plan for scheduling of future milestones down
> in print.

> 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.

> Questions or Thoughts?