RapidRelease: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(edited to use wiki syntax)
(this page is very outdated; replace it with a redirect to Release Management/Release Process)
 
(74 intermediate revisions by 8 users not shown)
Line 1: Line 1:
The Mozilla project's plan is is to introduce much faster releases provide regular improvements faster to users without disrupting longer term work.
#REDIRECT [[Release Management/Release Process]]
 
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:
http://mozilla.github.com/process-releases/
 
And some direction on further breakdown is at:
http://groups.google.com/group/mozilla.dev.planning/msg/fd41d944e0979caf
 
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 12
* every 6 weeks there after we pull to fx-dev
* 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 was being run by Ehsan and is winding down for mozilla-central pre-landing
 
=== Branch pulling ===
* stabilize after pull to downstream branch (ie post mozilla-central to fx-dev)
** avoid closing upstream branch (ie m-c) during stabilization
 
=== Feature & Major Change Policy ===
* kill switched or easy to back out
* forward proofed (config, data)
** at most backward and forward one version ie experimental vs mozilla-central
* dev takes the pain of backing out!
 
=== Fix Landing ===
* how does a bug fix for firefox-beta land
** it lands in all places (m-c, experimental, beta)
 
=== 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
*** From fligtar: it's a hassle for AMO and probably others (metrics, SUMO, socorro?) when we create versions like this that will eventually have to be manually mapped to other versions (3.1 => 3.5, 3.7 => 4.0). And the Compatibility Reporter was ready to go for 5.0a1pre builds and we're now having to  rush a version to support 4.2. Plus, it just adds confusion for add-on developers and everyone else who thought Firefox 5 is coming next. Our version system is complicated enough; we really shouldn't do things like this to make it worse.
 
=== 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
** branch team is taking over for 4.0.1
* 5.0 and newer processes will not be "backported" onto 4.0.x and older releases
 
== In Progress Actions, Unresolved Decisions and Their Owners ==
 
http://mozilla.github.com/process-releases/
 
=== 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
* Branch naming proposal John O'D
** http://groups.google.com/group/mozilla.dev.planning/msg/30c67403ddad9a7e
 
==== L10N and I18N [legneato, smooney, axel, choffman]  ====
* how to ensure minimal churn and max translation time [Axel, Christian, Sheila]
* probably 8 locales track m-c
** rest will follow up fx-experimental
* Legneato will clarify this in his doc
 
==== Branch Merging Mechanics ====
* do not delete experimental, merge from m-c
* track to see how much of a problem we get with backouts/preffing off
* the first merges will be manageable
 
=== Beta Channel Distribution [smooney, rs, limi] ===
 
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.
 
* Meetings to work on this are at https://wiki.mozilla.org/Firefox/Features/ChannelSwitching
* Supporting code tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=386760
 
* Better discoverability of version information for SUMO, Input, Bugzilla as we break these ups
 
=== Best Practices Feature Landing [engineering teams] ===
 
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
* kill switch removal http://groups.google.com/group/mozilla.dev.planning/msg/3a8e2c6c72cc2fff
 
=== Security Updates [chofmann, dveditz, legneato] ===
* the priority is last release branch
** we fix on all branches
* needs follow up on shadow repo possibilities
 
=== Updates ===
* Current proposal is no 5.0.x, 6.0.x etc updates other than chemspills
** based off the 6 week m-c pull cycle
** each release can be marketed in a different way
* Needs re-evaluation at FF6 to fx-experimental pull
 
=== 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.
 
* https://wiki.mozilla.org/Firefox/Features_List
* https://wiki.mozilla.org/Firefox/Flight_Tracking
 
=== Add On Compatibility [fligtar, jorge] ===
* reducing breakage and retaining compatibility
** IDL file diff possibility to notify people proactively
* recompile forced for FF5 already http://hg.mozilla.org/mozilla-central/rev/200a746e0fac
 
=== QA [rob, matt] ===
* as QA gets inserted, need clear suspension/resumption criteria for conflicts like chemspill vs release
* beta feedback is a big chunk of is it shippable feedback, and we are reducing it
 
=== Platform Consumer Outreach [jpr, kev] ===
* Linux distribution that need to be prepared for speed of shipping
* ATV outreach (screen readers, etc)

Latest revision as of 22:33, 23 May 2013

Redirect to:

Retrieved from "https://wiki.mozilla.org/index.php?title=RapidRelease&oldid=659889"