Electrolysis/Meetings/2015-05-04
e10s Rollout to Aurora meeting notes
Present: jim, larissa, brad, lawrence, milan, dave c, dave t, maire, felipe, gavin, liz, chad, doug, vladan
Expected rollout plan, double the time for each:
Ride 40 to Aurora
2015-05-11
Ride 41 to beta
2015-08-10
Ride 42 or 43 to release
2015-11-02 or 2015-12-14
Bug Lists
Aurora blocker list - http://is.gd/4v9Qxq (18 bugs open)
Beta blocker list - http://is.gd/gL9Qfj (121 bugs open)
e10s Team Aurora Uplift Checklist:
Dry run merge to aurora with test runs, work with tree managers
Announcing on dev.platform (early!)
Dev tools sign off (Eddie, dcamp)
https://etherpad.mozilla.org/devtools-e10s-statuses
Final pre or post merge code changes? ifdefing? build config?
bug 1156613
Async plugin init decision
Aaron is in charge of this, will disable on aurora without changes.
QA walk through of advanced aurora build looking for major issues
Who organizes this? Can we use Softvision?
test disabling e10s
What is our mitigation strategy?
Is e10s more stable than non-e10s?
Need to fix GNP crash reporting (bug up for review)
Lawrence has a list of additional features to test he is sending to Jim M.
a11y plan: a bunch of fixes were just landed but other features do turn it off - the a11y team is working on this with a goal to land stuff in 42
Why go to aurora when there are so many open bugs?
Add on developers won't work on issues till it hits aurora (or even beta)
Bugs coming in off Nightly have decreased a lot.
How many people are using Nightly on e10s?
How do we deal with e10s+ally on aurora?
The main issue now is add-on compatability, the other remaining bugs are "polish"
Round Table:
jimm
do we need to have a separate test coverage / automation meeting?
blassey tells me blake is looking into defining what we need here to move forward with each merge.
support issues around 2015-12-14?
dcamp
A note about aurora/dev edition usage patterns for consideration.
Anecdotal evidence is that people are moving to dev edition from nightly because of e10s This cycle is specifically bad for pushing to dev edition because of the marketing push this release (40).
We need: more testing and add-on testers to move along. We could turn off add-ons in dev edition and tell them they have to test aurora, but there may be a conflict with that and add-on signing testing in dev edition.
We also could push more Nightly folks to test
What extra data are we hoping to get? We could run it for two weeks and then turn it off for the june test
lmandel via email
known issues that the team is willing to accept?
Lots, we triage everything and drop bugs into buckets based on severity. Some block uplift to aurora, some block beta uplift, some block release uplift. Still lots of work to do here.
major issues? none that we know of.
performance impact of this feature?
any expected impact on the gfx team, who are pretty overloaded already?
impact on add-ons and plug-ins - what changes, if any, do add-ons need to make to support e10s
impact on crash reporting - will content crashes continue to be reported?
impact on other reporting systems such as FHR, Telemetry, about:support, about:memory, etc.
We have telemetry data being collected but no dashboard integration.
bug 1153928 - Get content process telemetry integrated and displaying
Not sure about FHR
about:support works, about:memory works (bug 1155163)
expectations about disabling e10s on Aurora if significant new issues are discovered
mitigation strategy for users who have significant issues - should we recommend that they simply disable e10s? how long will this configuration be supported?
Turn it off is the simplest work around. We can confirm this works reliably in aurora builds.
Non-e10s will continue to be support for a while, will be available all the way out to release and beyond.
We will continue to run mixed tests as well.
For example: a11y will not roll out with us, we will be prompting to disable when we detect problem a11y clients.
Why would we uplift to aurora when we have 100 open bugs? we have 18 that will be closed for aurora and the rest are triaged to be fixed before uplift to beta.
Reasons to move to Aurora
We want to get this out before security conferences spring 2016
motivating add-on developers
wider test audience
security conference related deadlines
there is documentation on how to do add-ons in e10s on MDN
devedition feature (performance monitoring timeline) relying on e10s for 40 (there is a workaround)
Concerns/reasons against:
why not fix more bugs for one more cycle and ship a more stable product
marketing push tied to dev edition for fx40
the add-on changes conflict/compound with signing and other changes
Options:
we could move and then move back before 40
we could go ahead with the plan to ship in 40
we could hold for 41 and fix bugs for another cycle and push nightly users to test
we could put it in 40, pref it off, and aggresively nag dev edition people to turn on e10s
Data points:
Crash data is lower for e10s than non-e10s on 40
parent vs child process crashes - the content process crash rates are way down but we havent run that comparison
Blocking list for aurora could be complete in july or we could complete all the bugs and ship in 44, both of them put at risk the org goal of shipping e10s within 2015.
Decision:
Warming cycle, e10s preffed off but with an opt in with a "nag" for 40, full test for 41
we can turn it off if things go substantially sideways and wait until 41 and try again.
we want to make sure telemetry is on appropriately (there is no apples-to-apples measure for tab switching but there are now telemetry probes)
