On Wed, May 1, 2019 at 10:27 AM Jonathan Kew <jfkth...@gmail.com> wrote:
> On 01/05/2019 17:29, Randell Jesup wrote: > > Jean-Yves writes: > >>> If anyone is chomping at the bit to remove 1proc support from their > module, > >>> please speak up. > >> > >> I am one of those developers that find non-e10s essential to debug core > features. > > > > I've depended on using non-e10s for ages as well. Most of my debugging > > can in theory be done in e10s, but whenever I have to have multiple GDBs > > running, and deal with breaking in one causing breaks in the other (or > > timeouts, etc), it's really painful, and especially for any work that > > crosses the Content/master boundary. > > Just chiming in to agree strongly here. Most bugs I investigate are in > code that doesn't care whether the browser is running in e10s or > non-e10s mode, and so I routinely use --disable-e10s to make my > debugging sessions simpler. Losing that option would hurt. > > I realize the time may come when it's impractical to keep non-e10s > working, but let's not kill it until there's a compelling reason to make > the sacrifice. > 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. bholley > JK > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
