The e10s team would like us to schedule e10s tests on Windows; we're currently only running mochitest-browser-chrome on Win7 opt and Win8 opt. Since these platforms are already over capacity, we'll likely do this periodically and piecemeal, and this bug will act as a tracking bug.
Blake, what suite should we target first here?
Candidates are: mochitest-plain, mochitest-devtools-chrome, reftests, crashtests, jsreftests, web-platform-tests, web-platform-reftests, Marionette, update-tests, media-tests
It looks like the current status of Windows tests on e10s is unknown. I've just merged m-c to holly (last done in July!) to see where we're at; chances are there will be some work needed by the e10s team to fix or disable tests before we can look at turning them on for try or trunk branches. https://treeherder.mozilla.org/#/jobs?repo=holly
Looks like tests on holly have been turned off, so we'll need to do this on try. What prefs do I flip to accomplish this?
The mozharness config files moved so my old config patch is bitrotten. Looks like the new files are here - http://mxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/unittests/ Looks like we can add '--e10s' to suite_definitions for the suites we want e10s turned on in. jittest, mochitest, and reftest look like the right candidates.
That's not exactly what I mean; I mean, which prefs do we need to flip in order to have the browser running in e10s mode regardless of whether we pass --e10s or not? That's the best way to make a try run for something like this.
ghetto try run with the --e10s hack for mochitests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6fe342dcb884
The try run isn't looking too good! Looks like a fair amount of work is needed to green up mochitest-plain; mochitest-devtools-chrome looks like the easiest to clean up. Jim, I'm passing this back to you; as soon as these suites are green we can turn them on more broadly, but not until then. Let me know if there's anything else you need in the meantime.
Blake is heading this aspect of the project up so I will defer to him on what to do next. FWIW I've got twalker working on adding browser chrome, I'm not aware of anyone working on mochitest-plain, and dev tools tests are the responsibility of the dev tools team.
How we're currently planning on freeing up enough capacity on Windows test machines in order to enables e10s tests, after they're green: https://groups.google.com/forum/#!topic/mozilla.tools/kihsolW9IQE
I don't thinks are as dire as comment 8 suggests. It looks like there might be one or two tests per mochitest chunk that are failing, causing everything to be orange but relatively little work to make each chunk not be. I'll start filing bugs (leaving the needinfo to do that) on making these green.
new try run to check status: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f439ce85793b
(In reply to Jonathan Griffin (:jgriffin) from comment #13) > new try run to check status: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=f439ce85793b mochitest-gl is ready to turn on now, mochitest-devtools-chrome is close; just a few failures remaining. More works is needed on mochitest-plain and reftest.
This is running, now https://wiki.mozilla.org/Electrolysis/Test_Coverage. jgriffin can we resolve this as fixed or do we need to wait until we have capacity problems resolved.
There are two suites not running on Windows 7 debug due to unresolved leaks or crashes. But I think it's ok to leave this metabug marked as fixed.
Yeah, future work can happen under bug 1253849.