My understanding is shipping e10s is the top priority, so I believe that
implies running tests there is (slightly) favoured.
But I like your idea for a dual mode. I'm on the fence whether it would
be a good default or not as it will double the time to run tests
locally, and many people likely don't need to test both (as try will do
it for them). This might be a good use case for command aliases (landing
soon in bug 1255450 hopefully).
Andrew
On 03/04/16 11:51 PM, Blair McBride wrote:
Default options imply the default is somehow favoured over the
non-default. Which, for this, makes me wonder: Is getting tests passing
on non-e10s less important now?
I've found the ergonomics around testing both to be quite a footgun -
it's a manual process to run tests under both modes, and it's too easy
to forget to run tests under the other mode. Would be handy to have a
switch to enable running under both modes (or even better, defaulting to
both modes).
- Blair
Andrew Halberstadt wrote:
Bug 1243083 tracks enabling e10s by default when running tests locally.
I intend to do this for as many harnesses as possible unless someone
says otherwise.
The implication is that the --e10s flag will be renamed to
--disable-e10s. So you'll need to pass in --disable-e10s if you wish to
run without e10s enabled. This also means that tests that are skipped
with 'e10s' will no longer run by default locally. The hope is that this
will make it easier for devs to find and fix tests that are broken with
e10s enabled, as well as ensure that new tests work with e10s right out
of the gate. CI jobs will not be affected, only running locally.
One potential sticking point is mochitest-chrome. It currently does not
get run in e10s in CI, so local configuration should mirror this.
However, since --e10s is being removed, this means it would be
impossible to run mochitest-chrome in e10s without modifying source
files. Maybe this just needs some argparse hackery.
If you have any concerns or know of other suites that should explicitly
*not* be run with e10s enabled by default, please let me know.
Andrew
_______________________________________________
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
