Currently, various Try syntax parsers assume "all" if values are missing. e.g. the TC Try syntax parser I'm reviewing in bug 1258497 (which I believe copies behavior from the existing Try syntax parser which I believe copied behavior from buildbot's Try syntax parser) assumes "try: -b o -p all" expands to "try: -b o -p all -t all -u all." Given the Windows and OS X tester capacity problems we're currently experiencing, I think the default behavior of the Try syntax parser should be more conservative: if someone doesn't request a job, we should not schedule a job. Or, something like "try: -b o -p all" would only do something like schedule unit test and talos jobs on linux64, where we have capacity. I'm pretty sure there have been conversations about this in the past. But OS X and Windows tester capacity right now is a big problem. Anything we can do to schedule fewer, unnecessary jobs will help.

end of this week, we should have ~25 windows7 test jobs in AWS- possibly more each week as we get some tests rearranged and sorted out.

I hadn't heard that about Windows testers in AWS. Will we be running them in parallel or will be shifting jobs to AWS and thus reducing load on our physical Windows testers? I've been told its several months until the new Macs are racked. As much as I want to say "let's just wait for more capacity" I don't think the timetables agree. Our Mac capacity situation isn't as bad as Windows. But wait times on Try are frequently several hours.

the windows 7 tests in aws are being worked on here: https://bugzilla.mozilla.org/show_bug.cgi?id=1271355 I am expecting that to be live by this weekend- if it slips we talk in days, not weeks.

this bug would encompass buildbot and taskcluster, I read bug 1244176 to be taskcluster only.

Well, whoever wants to self-assign it can re-open it :)

I would rather leave this open- there is a tracking bug which this is part of.

Do we have any reason to believe this would have any effect on load? As in, actual trychooser syntax use (other than my pushes today trying to figure out what actually worked with the defaults) which does omit params to make use of the defaults? The only thing that comes close that I know of is that Old People still use "try: -a" despite buildbot having "removed" support for it in 2011, which didn't remove it, just changed it from giving -b do -p all -u all -t all to giving -b do -p all -u all -t none. We certainly need to do something about that, for developer productivity and non-stupidity, since taskcluster lacks any default at all for -b so that now means "run everything on buildbot and nothing on taskcluster which you won't even notice until you get mad about being backed out over Linux64 debug or Android debug or ASan", but I'd bet that the most common try syntax by an incredibly wide margin is "-b do -p all -u all -t none" to which they would switch if we changed the defaults to finally actually remove -a. If you want to affect behavior, though, you'd have to do it by making it a pain in the ass to run all of anything, by removing support for -p all/-u all/-t all and instead require that people who want all click every single box in the form. And doing that would require that we make every single box both actually exist, and actually work, neither of which are currently true, and they've probably only both been true at one time for less than 5% of trychooser's life, which gives you a dependency on the abandoned bug 983802.

^^ Andrew, does that feed into your thinking about the future of try?

In my future vision, the try parsers don't exist anymore (or are at least moved from the backend to the frontend), so this bug would be mostly moot. But in the short term, I'd be inclined to agree with philor and just remove 'all' support from -p/-u/-t. We could still provide an "all" shortcut in trychooser/curses ui that automatically selects everything if we wanted. At least that way it would be obvious and explicit what 'all' expands out to. I also agree that we need to guarantee that what shows up on trychooser/curses ui 100% reflects what is actually possible to schedule, and the process to keep them up to date needs to be automated.

at least now we only have a single parser to worry about...