On a high level - try is a great tool and we want to make tools available to people when they are helpful to them. That includes parallelism, which is an important part of efficient bug hunting.
My inclination is that policy and bureaucracy are exactly the wrong mechanisms to put around a productivity tool like try. We should focus on making it work better and let people use it to shape a brave new world of their own vision. That probably means * more available hours * running less stuff by default (1 platform, no talos.. don't run tests for every platform of the same build) - but not having rules about what you can run or how often. Nagging "are you sure" thresholds could be helpful. * do we have a big mismatch between cpu hours and testing hours that virtualization would fix? maybe we need to bite the bullet on that one. (I've read the posts about the downsides) * breaking up our big tests into smaller chunks. I spent a long time last week on a osx 10.8 debug mochi-other leak. The leak measures all of mochi-other, so that's the big test I had to run. First - there is no easy way to break it down for your runs (I have certainly patched it by hand), and second the leak depended on multiple tests being run (and some raciness) and I never did figure out the exact combination of factors.. I don't find it especially more or less likely that if the test was broken down into 20 pieces it wouldn't have still shown itself. Second - each run tested 10.6, 10.7, and 10.8 (I usually killed 10.6 and 10.7, but i had to wait for the build to complete before doing so and sometimes I forgot). I used a lot of try time, and it was still laborious. Without parallelism I would however still be working on it. Without try at all we'd be stuck. If I had to beg for exceptions to let me use the tool I'd probably just go find a job where they wanted to get real work done instead. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
