The first intended use for |./mach try| was to select a small number of tests, and its strategy of putting everything in one chunk is ok for that (although this breaks down for harnesses that are chunked on some suites and not for others), but with bug 1184405 we're going to end up in situations we need to select lots of tests (entire test flavors), so we need to dynamically select a number of chunks to schedule, where applicable. The basic thing to do is easy now that we have run-by-dir almost everywhere, because we can "re-chunk" with impunity. But we're running up against the limitations of try syntax in other places.

This is related to bug 1198341, I think if we were able to do our scheduling through mozci/BBB we wouldn't have the try syntax problem of selecting one chunk where harnesses are chunked on some platforms but not others.

As we spoke in our meeting, we can have a special file where we put all desired scheduling into the last commit message (instead of the try syntax). The gecko decision task could read this file to know what BBB jobs to schedule. We can also teach the gecko decision task to create a graph based on files touched. In general, I think that if we have a python package (instead of being ingrained under |mach try|) which can generate a graph based on a code change. This module can be used inside of mach try as well as internally to mozci. That way we don't lock the power in a specific place. The most important thing (as I mentioned in my email) is how do we turn a code change into a set of platforms with their set of associated jobs (running in special or smoke test mode) we need. I assume the special tests or smoke tests work not only for chunked suites.

Yes, this is the general approach. The problem to solve in this bug is when to chunk the initial set of prioritized tests. The moz.build annotations have the flexibility to say that a large number of tests are prioritized for a change (if there are certain changes to layout that mean all reftests should run, for instance). At some point when building our graph we will need to determine whether the prioritized set needs to be chunked, and if so, how many chunks are appropriate.