On 4/25/13 1:12 PM, Ed Morley wrote: > On 25 April 2013 20:14:10, Justin Lebar wrote: >>> Is this what you're saying? >>> * 10.6 opt tests - per-checkin (no change) >>> * 10.6 debug tests - reduced >>> * 10.7 opt tests - reduced >>> * 10.7 debug tests - reduced >>> >>> * reduced --> m-c, m-a, m-b, m-r, esr17 >> >> Yes. >> >> Now that I think about this more, maybe we should go big or go home: >> change 10.6 opt tests to reduced as well, and see how it goes. We can >> always change it back. >> >> If it goes well, we can try to do the same thing with the Windows tests. >> >> We should get the sheriffs to sign off. > > Worth a shot, we can always revert :-) Only thing I might add, is that > we'll need a way to opt into 10.6 test jobs on Try, in case someone has > to debug issues found on mozilla-central (eg using sfink's undocumented > OS version specific syntax).
So what we're saying is that we are going to completely reverse our previous tree management policy? Currently, m-c is supposed to be the tree that's safely unbroken, and we know it's unbroken because the tests that we run on it have already been run on the tree that merged into it, and you should almost never push directly to it unless you're in a desperate hurry to hit a nightly. This change would mean that we expect to have merges of hundreds of csets from inbound sometimes break m-c with no idea which one broke it, that we expect to sometimes have permaorange on it for days, and that it's better to push your widget/cocoa/ pushes directly to m-c than to inbound. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
