Last fall, we got Talos working on e10s and scheduled e10s-specific jobs on mozilla-central and holly.

It looks like sometime in the last few weeks something broke talos-on-e10s on an integration branch, and now all the jobs are broken:

https://bugzilla.mozilla.org/show_bug.cgi?id=1134238 ("all talos on e10s fails to run since Feb 10th")

Do we realistically care about keeping this working? With perfherder graphs, we now have a way of visualizing/tracking relative performance (http://wrla.ch/blog/2015/02/measuring-e10s-vs-non-e10s-performance-with-perfherder/), though I'm not sure if that's really telling us anything we don't already know.

If we *do* decide we care about these results, I think we should (1) enable e10s runs on integration branches and (2) commit to backing out commits that break talos on e10s (i.e. unhide them). That is to say, we should also fix this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1130445 ("Unhide Talos e10s when it meets visibility requirements")

Note that doing this entails scheduling a significant number of additional jobs on the integration branches, maybe more than we have the capacity to support (Joel Maher could probably say more about this). On the other hand, if we don't genuinely care about talos-on-e10s-performance at this point (i.e. we're more concerned about correctness or performance issues which aren't really measurable by Talos), we should probably just turn off these jobs altogether and save some cycles. We can always revisit this decision later when e10s is closer to shipping.

Thoughts?

Will
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to