At present we aren't using openQA's 'job groups' feature at all. All our job templates get automatically assigned the group 'fedora', because job templates with the version '*' are assigned to a group named simply for the distri. Job templates with a specific version are assigned to a group named '(distri)-(version)'.

The major use of job groups is to arrange the front page. So if you look at openSUSE's openQA, 'Open Build Service', 'Staging Projects', openSUSE Tumbleweed' and so on are all job groups. So they get a nice full front page with lots of recent runs visible. We, on the other hand, get a front page full of whitespace with the last three runs for any release and that's it.

Ideally, given our current openQA use, we'd have groups for stable (or 'Postrelease' as fedfind calls it), Branched and Rawhide. Then we'd be able to see the last few runs for each release at a glance.

Unfortunately the way this is coded doesn't line up terribly well with how we have our jobs arranged. To do it the 'expected' way we'd have to duplicate the entire 'normal' job set, once with the version 'Rawhide' and once with the release number of the current Branched, which we'd have to somehow bump automatically or manually (or we'd have to give branched jobs the version 'Branched' instead of the release number, or something).

I'd sort of like to see if there's a way we could do this smarter, maybe by improving the way 'automatic job groups' are handled; perhaps instead of just assigning a group based on the distri at template load time, job templates could be assigned a 'special' job group like 'fedora-*', and the job creator code would know to turn that into 'fedora-(version)' at the time of job creation. Just thinking out loud, not sure if it would work. But it would be nice to somehow be able to do this without duping all the tests.

SUSE don't really have this problem as they don't have two dev branches it makes sense to run the same tests on; I suspect they have some duplication, e.g. between 'openSUSE Leap 42.1 Updates' and 'openSUSE 13.2 Updates', but those are fairly small job groups. So we would need to make sure any change we propose here isn't too crazy and doesn't disrupt their workflow at all, because they have no great incentive to accept one that's messy.