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? Or are we more concerned, long term, that non-e10s would block us from making some architectural changes to e10s? Relatedly, do we have a history of having broken non-e10s with e10s changes? Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
