Releases/Firefox 5/Risk mitigation strategies

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.

Dials we can adjust

Advertised vs unadvertised update

• We could offer an advertised (major) update rather than an unadvertised (minor) one

Pros

1. Gives users more notice / lets them opt-in
2. Ability to speak directly to users via the billboard
3. Users may be more tolerant of add-on incompatibility due to better mental preparation

Cons

1. Slows uptake
2. If the user chooses never we don't have a point release in a month reprompting them
3. More users exposed for longer if we announce security vulnerability details
4. 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

1. Minimizes risk to userbase while still being technically released
2. Gives users more notice / lets them opt-in (either from mozilla.com or checking for updates manually)
3. Users may be more tolerant as they explicitly looked for and installed the release
4. Press around release may prompt add-on makers to update their add-ons

Cons

1. Slows uptake considerably
2. Do we disclose security vulnerability details?
3. 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

1. Lowers risk across the entire userbase
2. Gives add-on developers additional time to increase compatibility

Cons

1. Gives some users more risk, others less
2. May be harder to see crash spikes as the user ramp is gradual
3. May be harder to get initial feedback as the volume could be too low to determine if something is a major issue
4. More users exposed for longer if we announce security vulnerability details