User:Jprosevear/RapidReleaseUpdate: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Replaced content with "See the Real Thing (TM)")
 
(70 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Overview =
See the [[RapidRelease|Real Thing (TM)]]
 
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#Meetings|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
 
= Unresolved or Unclear Decisions and Owners =
 
+ 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/i18n
+ how to ensure minimal churn and max translation time
 
 
+ how will nightlies be allocated to various channels
+ the mechanism
 
+ timeline for silent update implementation
 
+ best practices to ensure feature is "ready" for m-c
+ increased use of project branches?
+ https://wiki.mozilla.org/RapidRelease/LandingPlan
 
+ 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?
 
+ 5.0.x, 6.0.x etc updates other than chemspills?
+ based off the 6 week m-c pull cycle?

Latest revision as of 13:01, 1 April 2011