> For case 1., an idea that has been floated here and again (in Automation and > Tools and Release Engineering, anyway) is landing directly from try -> > inbound (or central) for green try pushes. However, this isn't a small > endeavor, both for the reasons of building the infra + software to do this > as well as the fact that since the average random oranges/push is high > landing is such a manual process. If this is something we want, though, we > should ticket it and estimate what this will really take.
A very simple way to approximate this would be the following policy: * If you have a recent green try build, you can land on inbound with DONTBUILD. I think this would likely result in even more headaches for sheriffs and is optimizing for load on the wrong tree (m-i is only 25% of our load, while try is 50%), but it would be easy to try out, so maybe we should do it for a day or two and see if the result is chaos. A more complex version of this policy would be to add a COALESCEME keyword which makes a push likely to be coalesced with other pushes. This could allow us to more intelligently coalesce builds on m-i. For example, suppose * we land W, X, Y, and Z all in a row within 10 minutes or so, * csets W and X have try runs and csets Y and Z do not, and * we have capacity for two builds then I'd rather get builds for [WX and YZ] than for [W and XYZ]. I still feel like all these attempts to lower load on m-i are probably a false economy, though. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
