On Wed, Apr 24, 2019 at 4:30 PM Mike Hommey <m...@glandium.org> wrote:
> On Wed, Apr 24, 2019 at 03:49:47PM -0700, Bobby Holley wrote: > > On Wed, Apr 24, 2019 at 2:21 PM David Major <dma...@mozilla.com> wrote: > > > > > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley <bobbyhol...@gmail.com> > > > wrote: > > > > > > > > Thanks Mike! > > > > > > > > So Fennec is the last remaining non-e10s configuration we ship to > users. > > > > Given that Fennec test coverage is somewhat incomplete, we probably > want > > > to > > > > keep running desktop 1proc tests until Fennec EOL. We don't strictly > need > > > > the browser-chrome tests, but we should probably avoid intentionally > > > > breaking non-e10s browser-chrome as long as engineers may still need > to > > > > debug non-e10s test failures. > > > > > > > > After Fennec EOL, we basically have two options: a clean break where > we > > > rip > > > > out non-e10s support entirely, or a more muddled approach where we > > > > halfheartedly keep it working as a handy engineering hack as long as > is > > > > practical. I think we should do the former. > > > > > > > > I don't want to downplay the handiness - being able to test and > debug the > > > > browser in a single process can eliminate complexity and > non-determinism, > > > > and save a lot of time. But at some point there's going to be a > piece of > > > > core functionality that's too much work to keep supporting under > > > non-e10s - > > > > and agonizing over that threshold on an ongoing basis is not a good > use > > > of > > > > anyone's time. > > > > > > Why not have the conversation when such a piece of core functionality > > > arises? It's a much more convincing argument when you can say > > > "non-e10s needs to go away in order to support X". > > > > > > > I'm concerned about the impact of a gradual degradation of the e10s > > experience and an ambiguous bar as to exactly how much work developers > are > > expected to do to support it. It's effectively going to be a Tier-3 > > platform with no owner. > > > > > > > > > > In the meantime, single process debugging is a tremendous saver of > > > time and hassle, and we'd need a great reason to disable it. I'm not > > > convinced that one currently exists. > > > > > > > I think the tradeoff boils down to (a) how many developers are using > > non-e10s debugging, with what frequency, versus (b) how much ongoing > > maintenance work is required across various components to keep non-e10s > > working. We all have intuition about these things, but I doubt we have > hard > > data. > > > > I'm open to the argument that my proposal is too aggressive. We could > > certainly try the muddle approach for a while and see how it goes, and > how > > often 1proc breaks in practice. I don't think we can justify continuing > to > > run the full suite of 1proc tests as tier-1, but we could potentially > run a > > few smoketests, which might keep the builds usable enough for debugging. > > > > If anyone is chomping at the bit to remove 1proc support from their > module, > > please speak up. > > I'm not versed on the details of non-e10s, but is it so different from > e10s that it could easily break? Probably not "so different" in relative terms, since we try to abstract over the distinction wherever possible. But browsers are big and abstractions are rarely perfect, so there's a long tail of special-cases that do different things depending on the process model. If we're not testing it, it will eventually break. > Or are we more concerned, long term, > that non-e10s would block us from making some architectural changes to > e10s? > If a big architectural change gets blocked (which will probably happen eventually), that will simplify the discussion. So I think the question here is how much fiddling we should do to keep it working in the interim. > Relatedly, do we have a history of having broken non-e10s with e10s > changes? > I doubt there's a comprehensive list, but bug 1530977 is the example that recently came across my desk. That bug is specific to hardware acceleration on Windows, which is why it wasn't caught by the linux 1proc tests. Once we those off, the regression surface will widen from platform-specific code to all of Gecko. I suspect that will result in an increased rate in regressions, but it's hard to guess exactly how much. > > Mike > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
