2017-06-01 10:54 GMT-04:00 Andrew Halberstadt <ahalberst...@mozilla.com>: > Speaking for myself I agree that it seems unlikely we'll be able to both > reduce machine consumption and increase test coverage, and I think that's > fine. When I read dustin's proposal, I see: > > #1. The interface to try is terrible, we should fix that > #2. There is some scheduling we could be doing automatically, we should be > smarter about that
Thanks, that's a great summary :) I agree that they are independent, but they generally bleed together in discussions so we should probably address them both at the same time. For #2, there's a clear risk of over-doing it, introducing complexity and failure modes. Let's not do that. There's also a risk kof optimizing the wrong thing -- for example, being really careful about when an eslint job runs is silly, because eslint is fast and easy. We will see better value in optimizing for constrained resources -- specifically, tasks that have to run on Mozilla-owned hardware fo which we have a finite supply, such as OS X, especially if we can optimize those jobs away on integration branches. And if we stick to the 'very damn sure" rule, we can avoid increasing the backout rate. In talking to Ben, I realized this was proposed as if it was a major project that would take a few engineers a few months. That's my mistake -- rather, this is a design proposal to guide work that is already underway (we are optimizing already) or planned (such as ahal's try work). The idea is to make sure that this work proceeds in a consistent, positive direction. So! I'll put this into a google doc to which we can all refer when our work touches on optimization or try, and post the result here for review. Thanks for the comments so far :) Dustin _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
