RapidRelease
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: 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/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.
- AMO people request there is better planning around versions
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
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.
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)