We agreed that at least as a short-term stop gap, we'll have the openQA scheduler report some kind of test 'priority' to ResultsDB, for releng to consume for gating purposes.

Ideally we'd be able to set an openQA var in the job templates, but we can't, they don't let you do that. (Though we could possibly get that changed upstream). @jsedlak had the idea of using the openQA job priority to encode this, which I was kinda doing already (with a scheme that went something like 10 = basic install tests, 20 = Alpha, 30 = Beta, 40 = Final, 50+ = Optional or something like that, with the other digit being 0, 1 or 2 depending on some combination of the image being tested and whether the test is UEFI or not, I forget). There's certainly enough granularity there to get started.

I think a reasonable scheme would be something like priority.fedora.compose.0, where 0 indicates the priority, and we can indicate the product and the process (so tests can have different priorities in different processes for different products, potentially). How's that sound? We should run this by Dennis and maybe Ralph at least...