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