On 01/05/2019 19:01, Bobby Holley wrote:
This thread is getting long, so here's a quick recap:
* It it well-understood that a number of developers use --disable-e10s as a
debugging aid, so more +1s to that effect aren't needed.
* The "please speak up" is aimed at developers who want to _remove_ 1proc
support.
* The compromise plan of record is to keep a small subset of 1proc tests as
tier-1. So basic functionality should continue to work, but stuff around
the edges may break.
* Alternative proposals to the above are welcome, but please be concrete
and weigh the trade-offs.
* If there's specific functionality you want to keep testing in 1proc mode,
please mention it in bug 1548035.
To add a bit more motivation for the proposed plan: Continuing to run the
entire test suite in 1proc mode costs money and developer time. The quality
bar of builds that ship to users is _much_ higher than the bar for builds
used as debugging hacks. If a single test starts failing in 1proc mode
only, the right answer is probably to turn the test off rather than spend
developer time chasing it. What we want to prevent are the sort of
across-the-board breakages that make the browser unusable for debugging -
and we can detect those with a much smaller subset of tests than what we're
presently running.
I think narrowing test coverage for 1proc on 69 is fine, but I'd like to
do something for 68 still. Specifically, I strongly feel we should not
continue to support the "turn off e10s with a pref" scenario when it's
so loosely tested - as you said, the bar for builds that ship to users
is much higher. On nightly, about:newtab/home (activity stream) is
completely broken and the bug to fix it was marked wontfix due to us not
supporting e10s (this bustage relates to the privileged content process
which is held to nightly, so won't ride the trains with 68... but no
idea what other bustage there might be that will [ride the trains]).
So, although this is in addition to what you're suggesting, a concrete
proposal: I've put up a patch at
https://phabricator.services.mozilla.com/D29892 /
https://bugzilla.mozilla.org/show_bug.cgi?id=1548941 .
This continues supporting the pref for:
- non-Firefox (hi TB/Fennec/SM/...)
- automation
- non-official builds (like local developer builds)
In official builds, the pref will be ignored and e10s is always turned
on. The only way to turn it off there is the environment variable
MOZ_FORCE_DISABLE_E10S which we already supported (so if you desperately
needed to debug something in non-e10s on an official build, you still
could).
For 69, I think we could remove the pref entirely and transition
everything into the env var (incl. test suites, where 1proc ones
currently just flip the pref), to further reduce confusion and
maintenance burdens, and I'd plan to remove various bits of browser
chrome code specific to (non-critical) bits of non-e10s.
Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
