User:Jprosevear/RapidReleaseUpdate

Overview

The Mozilla project's plan is is to introduce much faster releases provide regular improvements faster to users without disrupting longer term work.

A draft for the high level proposal of this process is at: http://people.mozilla.com/~sayrer/2011/temp/process.html

A detailed process plan is being worked on by Christian and Sheila. [need ETA]

The next checkpoint for discussing this process and its evolution will be March 29 in the platform/development meeting

Current State and Decisions

The following is a list consisting of items in a steady state for this process or decisions that have been made and generally agreed on in the project.

mozilla-central

• open for a 3 week period starting March 23 and ending April 13
• build sheriffing will [link to bsmedberg's mail?] focus on high gain, low risk items
• cedar is being run by Ehsan and is available for pre-mozilla-central landing
  • the focus so far here is on patches with approval for 2.0 [check this]

+ features and major changes must be + kill switched or easy to back out + forward proofed (config, data) + dev takes the pain of backing out!

Version Numbering

• version number of 2.2a1pre/4.2a1pre
  • AMO people request there is better planning around versions [need cite]

User Agent

• nothing other than 5.0 versioning for mc/dev/beta

Nightlies & Beta Channel

• Nightlies stay on mozilla-central
• Beta users stay on beta channel with no updates
  • This may change in future with audience partitioning

4.0.x

• there will be 4.0.x releases and chemspill handling

In Progress, Unresolved and Unclear Decisions and Owners

Release Driver Meetings

+ go/no-go and release meeting prep

+ how to manage 3 in-flight release paths at once + we can say "no" to some of the possible 6 week releases + must be careful though not to fall into longer release traps + by waving more than 2 in a row

L10N and I18N

• how to ensure minimal churn and max translation time [Axel, Christian, Sheila]

Beta Channel Distribution

• Rob Strong code
  • Landed yet?
• Front End Code?
• Policy

Best Practices Feature Landing

Features must be "ready" for landing on mozilla-central, in general this is up to module owners, sheriffs and teams, but building a set of best practices would be ideal.

• possibly increased use of project branches
• https://wiki.mozilla.org/RapidRelease/LandingPlan

Fix Landing

+ how does a bug fix for firefox-beta land + who does it? + does it land in multiple places at once? + m-c first and cherry picked as appropriate?

Updates

+ 5.0.x, 6.0.x etc updates other than chemspills? + based off the 6 week m-c pull cycle?