<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 3, 2016 at 11:51 PM, Blair McBride <span dir="ltr"><<a href="mailto:bmcbride@mozilla.com" target="_blank">bmcbride@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br></blockquote><div><br></div><div>Fennec doesn't use e10s, so at least for tests that cover both desktop and Android, they're both equally important.  Plus, as I understand the plans, we're going to be shipping e10s and non-e10s on desktop at the same time to different users at least for a while.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<span class="HOEnZb"><font color="#888888"><br>
<br>
- Blair</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
Andrew Halberstadt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bug 1243083 tracks enabling e10s by default when running tests locally.<br>
I intend to do this for as many harnesses as possible unless someone<br>
says otherwise.<br>
<br>
The implication is that the --e10s flag will be renamed to<br>
--disable-e10s. So you'll need to pass in --disable-e10s if you wish to<br>
run without e10s enabled. This also means that tests that are skipped<br>
with 'e10s' will no longer run by default locally. The hope is that this<br>
will make it easier for devs to find and fix tests that are broken with<br>
e10s enabled, as well as ensure that new tests work with e10s right out<br>
of the gate. CI jobs will not be affected, only running locally.<br>
<br>
One potential sticking point is mochitest-chrome. It currently does not<br>
get run in e10s in CI, so local configuration should mirror this.<br>
However, since --e10s is being removed, this means it would be<br>
impossible to run mochitest-chrome in e10s without modifying source<br>
files. Maybe this just needs some argparse hackery.<br>
<br>
If you have any concerns or know of other suites that should explicitly<br>
*not* be run with e10s enabled by default, please let me know.<br>
<br>
Andrew<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote>
<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Ehsan<br></div></div>
</div></div>