e10s Update: March 29

Executive Summary

• Overall, the phase of the project we currently in is best described as Convergence. For Firefox 47, the most likely scenario will be that we continue to conduct A/B Experiments in our beta channel until we can lower our rate of main process, content, and Plugin crashes. Our latest A/B experiment derived data set indicates we have work to do on stability before we're ready to ship to beta. We are, however, hitting our goals in many areas of our release criteria such as Page Load, Startup/Shutdown time, and Scrolling. We still have work to do in areas such as UI Smoothness, Plugin Jank, Memory Usage, and GFX Performance but not to the level that would necessarily block beta. We have made excellent progress in our cadence of deploying A/B experiments and quickly ascertaining the data so we have hit a place where we are tightly coordinated and people are empowered with the right data to move on issues swiftly. Another important thing to note is that we are currently using the System Add-On to deploy our A/B experiments so we are testing the mechanism we designed to ship e10s rather than using experiment code. The current experiment (add-ons + ally = no, apz= yes) will end later this week, in time for Beta 7 and we will have updated results soon thereafter.

• The team has shifted to burning down M9's [1]. M9 tickets need to hit zero before we're ready to do our cohort release for GA. M9 is focused on fixing issues derived from our Telemetry A/B experiments such as top crashes, regressions, and backlog items deemed to be blockers by product. We have hit a stage where a portion of the M9's are the responsibility of teams outside of the e10s team so we will be rolling those tickets into central triage managed by RelMan to help with load balance.

• With the approach of Firefox 47 merging to Beta on April 18, quality and market readiness remain our central focus.

Why yellow? e10s is designated 'yellow' or 'at risk' because:

Incoming data from our latest A/B experiment indicates we have more work to do on the stability side. Given that we are at week 4 in our dev cycle leading to Firefox 47 beta, we will likely continue to do experiments in Beta 47 vs. releasing to a % of our cohort population.

Highlights and Accomplishments

• Check out a summary of the engineering happenings last week: https://wiki.mozilla.org/Electrolysis/Meetings/2016-03-24
• We've also made great progress fixing automated tests; by early next week we will have owners for all tests
• WIP: manual test plan. Manual testing has been ongoing, this new test plan has new layout that is easier to follow along with risk commentary, etc. More to share soon on that.

Next Steps

• The main and content process crashes are well-documented. Next, we need to dig into the plugin crashes
• Triage the RC Blocker Meta dependency tree to identify other tasks that need to happen prior to GA (besides M9s)
• Now that we have a track back schedule which articulates what we need to accomplish in preparation for beta, we need to now create a precise roll-out plan. We should have something to share the week of April 7
• We will be reaching out to module owners to sign off on their efforts to fix automated tests in the next week

Release Criteria

• e10s release criteria status
  • We have telemetry data from phase 1 (e10s without APZ) of Beta 46 experiment.
  • Red release criteria:
    • MEMORY_TOTAL: 80% worse, but expected only 10%–25% worse.
    • SLOW_SCRIPT_PAGE_COUNT: 0.47 per hour vs 0.36 per hour
  • Some release criteria are all green/passing. Looking to sign-off on those criteria soon.

Add-Ons + WebExtensions

• Working on add-on SDK issues mostly related to e10s
• Outreach to add-on devs to help with e10s compat is ongoing
• Next steps include simplifying testing for SV, and identifying a plan for shim handling going forward

Automated tests

• Everything we can have enabled in production is enabled, everything else is enabled on a separate branch called 'Ash'.
• Goal to have all tests be owned by 03/25 (we're close)
• We would like each directory signed-off by test owners week of 04/07
• We're tracking all the tests and who owns them, here
• We are tracking tests that are running and passing on some platforms, but are disabled on others.From a feature coverage point of view, it's in pretty great shape. There's very little that is disabled both on opt *and* debug on a same platform (meaning that that test is not running on this platform). Look for the "Fully disabled in a platform" entries in this spreadsheet.

A11y

• Proposed technical path to encourage a11y clients to communicate directly with the content process bug 1258839. dbolter is getting some first impressions from clients to see if this is a viable approach.
• We're also looking into Windows touchscreen/a11y compat, see more information as the plan is taking shape, here.

Milestones

We are at the point where we are setting milestones weekly; given the complexity of deliverables, we are using a Trackback Schedule to keep everything organized.

Release Schedule