User:Jprosevear/RapidReleaseUpdate

From MozillaWiki
Jump to navigation Jump to search

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 focus on high gain, low risk items
    • bsmedberg communicating this to other build sheriffs
    • tree is closed when there is no sheriff
  • cedar is being run by Ehsan and is available for pre-mozilla-central landing
    • use this when there is no sheriff on duty
    • the focus so far here is on patches with approval for 2.0 [check this]

Feature & Major Change Policy

  • kill switched or easy to back out
  • forward proofed (config, data)
  • dev takes the pain of backing out!

Bugzilla

  • mozilla2.2 target milestone for mozilla-central

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 and Mechanices Process Meetings [legneato, smooney]

  • When are meetings about go/no-go and decisions about what to turn off made? [
  • 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 [legneato, smooney, axel]

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

Beta Channel Distribution

This is about how to divide up beta users into multiple testing channels for -dev and -beta. There are decisions about how to divide up the user base and there are supporting code changes to make this happen.

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.

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?

Feature Planning [dria]

Because of timelines, this process will not impact Firefox 5 very much, but should be come much more important in FF6 and full formed for FF7.

Add On Compatibility

Retrieved from "https://wiki.mozilla.org/index.php?title=User:Jprosevear/RapidReleaseUpdate&oldid=294056"