Why?
We need to see where we are at with various risk factors for Firefox 5 and ways to mitigate that risk if we aren't comfortable with the level.
This page / planning does not mean we NEED to do any of these or Firefox 5 isn't ready to release. It is merely prudent to discuss where we are at, what's in our control, and ways to mitigate risk before they are needed.
Current risk profile
Add-ons
- 78% compatible with Firefox 5 for the add-ons on AMO
- Large portion of the remaining percentage is the .NET Framework Assistant
- Talked with the developer at Microsoft, said he would update his add-on. We don't have a timeframe for the update though
- Risk: LOW for AMO add-ons. HIGH for non-AMO add-ons
- Most have updated, and the ones that aren't are waiting for release
- https://addons.mozilla.org/en-US/firefox/compatibility
- 78% of addons compatible
- .net framework assitant: ETA?
Will mobile fall under this action plan? (Caitlin)
Stability
- 1.7 million users on 5.0 overall.
- Crash rate fairly low at 1.36 crashes per 100 ADU.
- Distribution of users scattered across all betas - http://test.kairo.at/socorro/2011-06-16.buildcrashes.html.
- Risks
- No good data right now on any one beta for 1 million+ users.
- b7: 89K users, 6.799 crashes per 100 ADU.
- b6: 295K users, 1.436 crashes per 100 ADU.
- The last several betas have never increased much beyond 250K users.
- We know from 4.0 experience that the crash landscape changes above 1 million, 2 million, 5 million. We had over 2 million beta users for pre 4.0 builds.
- Not enough data to really understand if there is top crasher.
- 2 Flash releases in the last week and a half.
Security
Web compatibility
Dials we can adjust
Advertised vs unadvertised update
- We could offer an advertised (major) update rather than an unadvertised (minor) one
Pros
- Gives users more notice / lets them opt-in
- Ability to speak directly to users via the billboard
- Users may be more tolerant of add-on incompatibility due to better mental preparation
Cons
- Slows uptake
- If the user chooses never we don't have a point release in a month reprompting them
- More users exposed for longer if we announce security vulnerability details
- Requires webpage creation, copy creation, and localization--none of which has been done
Manual-only update
- We could only offer a manual download from Mozilla.com. Users would only get the in-product update if they manually check for updates
Pros
- Minimizes risk to userbase while still being technically released
- Gives users more notice / lets them opt-in (either from mozilla.com or checking for updates manually)
- Users may be more tolerant as they explicitly looked for and installed the release
- Press around release may prompt add-on makers to update their add-ons
Cons
- Slows uptake considerably
- Do we disclose security vulnerability details?
- Some may not view it as a release if it is only available when manual action is taken
Throttled automatic update offers
- Release as normal but have some percentage of update pings return no update available
Pros
- Lowers risk across the entire userbase
- Gives add-on developers additional time to increase compatibility
Cons
- Gives some users more risk, others less
- May be harder to see crash spikes as the user ramp is gradual
- May be harder to get initial feedback as the volume could be too low to determine if something is a major issue
- More users exposed for longer if we announce security vulnerability details