761
edits
User:Jprosevear/RapidReleaseUpdate: Difference between revisions
Jump to navigation
Jump to search
User:Jprosevear/RapidReleaseUpdate (view source)
Revision as of 13:39, 31 March 2011
, 31 March 2011no edit summary
Jprosevear (talk | contribs) |
Jprosevear (talk | contribs) No edit summary |
||
| 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. | |||
'''This page points you to canonical information sources and current discussions where possible. If something is not finalized or started, owners are attempted to be listed. | |||
A draft for the high level proposal of this process is at: | A draft for the high level proposal of this process is at: | ||
http:// | http://mozilla.github.com/process-releases/draft/development_overview/ | ||
A detailed process plan is being worked on by Christian and Sheila: | |||
http | http://mozilla.github.com/process-releases/draft/development_specifics/ | ||
Both are available in git so you can track changes: | |||
http://mozilla.github.com/process-releases/ | http://mozilla.github.com/process-releases/ | ||
Please direct discussion to the dev-planning mailing list: | |||
https://lists.mozilla.org/listinfo/dev-planning | |||
= Current State and Decisions = | == 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. | 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 == | === mozilla-central === | ||
* open for a 3 week period starting March 23 and ending April | * open for a 3 week period starting March 23 and ending April 12 | ||
* every 6 weeks there after we pull to | * every 6 weeks there after we pull to mozilla-experimental | ||
* build sheriffing will focus on high gain, low risk items | * build sheriffing will focus on high gain, low risk items | ||
** bsmedberg communicating this to other build sheriffs | ** bsmedberg communicating this to other build sheriffs | ||
** tree is closed when there is no sheriff | ** tree is closed when there is no sheriff | ||
* cedar | * cedar was being run by Ehsan and is winding down for mozilla-central pre-landing | ||
== Branch pulling == | === Branch pulling === | ||
* stabilize after pull to downstream branch (ie post mozilla-central to | * stabilize after pull to downstream branch (ie post mozilla-central to mozilla-experimental) | ||
** avoid closing upstream branch (ie m-c) during stabilization | ** avoid closing upstream branch (ie m-c) during stabilization | ||
== Feature & Major Change Policy == | === Feature & Major Change Policy === | ||
* kill switched or easy to back out | * kill switched or easy to back out | ||
* forward proofed (config, data) | * forward proofed (config, data) | ||
* | ** at most backward and forward one version ie experimental vs mozilla-central | ||
* developer takes the pain of backing out! | |||
== Bugzilla == | === 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 | * mozilla2.2 target milestone for mozilla-central | ||
== Version Numbering == | === Version Numbering === | ||
* version number of 2.2a1pre/4.2a1pre | * version number of 2.2a1pre/4.2a1pre | ||
** AMO people request there is better planning around versions | ** 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 | *** 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. | ||
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 == | === User Agent === | ||
* nothing other than 5.0 versioning for mc/ | * nothing other than 5.0 versioning for mc/experimental/beta | ||
== Nightlies & Beta Channel == | === Nightlies & Beta Channel === | ||
* Nightlies stay on mozilla-central | * Nightlies stay on mozilla-central | ||
* Beta users stay on beta channel with no updates | * Beta users stay on beta channel with no updates | ||
** This may change in future with audience partitioning | ** This may change in future with audience partitioning | ||
== 4.0.x == | === 4.0.x === | ||
* there will be 4.0.x releases and chemspill handling | * there will be 4.0.x releases and chemspill handling | ||
** branch team is taking over for 4.0.1 | |||
* there will be 3.6.x and 3.5.x releases and chemspill handling | |||
* 5.0 and newer processes will not be "backported" onto 4.0.x and older releases | * 5.0 and newer processes will not be "backported" onto 4.0.x and older releases | ||
= In Progress Actions, Unresolved Decisions and Their Owners = | == In Progress Actions, Unresolved Decisions and Their Owners == | ||
http://mozilla.github.com/process-releases/ | |||
== Release Driver and Mechanices Process Meetings [legneato, smooney] == | === Release Driver and Mechanices Process Meetings [legneato, smooney] === | ||
* When are meetings about go/no-go and decisions about what to turn off made? | * 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 | * How to manage 3 in-flight release paths at once | ||
* Branch naming proposal John O'D | * Branch naming proposal John O'D | ||
** http://groups.google.com/group/mozilla.dev.planning/msg/30c67403ddad9a7e | ** http://groups.google.com/group/mozilla.dev.planning/msg/30c67403ddad9a7e | ||
== L10N and I18N [legneato, smooney, axel, choffman] == | ==== L10N and I18N [legneato, smooney, axel, choffman, christian] ==== | ||
* how to ensure minimal churn and max translation time | * how to ensure minimal churn and max translation time | ||
* l10n repository naming | |||
== | ==== 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 -experimental 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 == | * Meetings to work on this are at [[Firefox/Features/ChannelSwitching]] | ||
* Supporting code tracked in {{bug|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. | 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 | * possibly increased use of project branches | ||
* | * [[RapidRelease/LandingPlan]] | ||
* kill switch removal http://groups.google.com/group/mozilla.dev.planning/msg/3a8e2c6c72cc2fff | * 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 | |||
== Security Updates == | |||
* | |||
* | |||
* | |||
== Updates == | === Updates === | ||
* 5.0.x, 6.0.x etc updates other than chemspills | * Current proposal is no 5.0.x, 6.0.x etc updates other than chemspills | ||
** based off the 6 week m-c pull cycle | ** based off the 6 week m-c pull cycle | ||
** each release can be marketed in a different way | |||
* Needs re-evaluation at FF6 to mozilla-experimental pull | |||
== Feature Planning [dria] == | === 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. | 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. | ||
* | * [[Firefox/Features List]] | ||
* [[Firefox/Flight Tracking]] | |||
== Add On Compatibility == | === Add On Compatibility [fligtar, jorge] === | ||
* reducing breakage and retaining compatibility | * 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 | * recompile forced for FF5 already http://hg.mozilla.org/mozilla-central/rev/200a746e0fac | ||
== QA == | === QA [rob, matt] === | ||
* as QA gets inserted, need clear suspension/resumption criteria for conflicts like chemspill vs release | * 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 | * beta feedback is a big chunk of is it shippable feedback, and we are reducing it | ||
== Platform Consumer Outreach == | === Platform Consumer Outreach [jpr, kev] === | ||
* Linux distribution that need to be prepared for speed of shipping | * Linux distribution that need to be prepared for speed of shipping | ||
* ATV outreach (screen readers, etc) | * ATV outreach (screen readers, etc) | ||