As I understood from the personal discussions we have the plan also only relates to osd and not o3. However, still I have talked to the openSUSE RMs what they think about multiple subgroups -> main question by dimstar was: what is the benefit for RMs when they mainly review and can we find a view to show the results from multiple job groups. I guess what we can think about is slightly changing the behaviour of "parent job groups" on the index page of openQA to provide a link to a test overview page which shows multiple job groups at the same time as referencing multiple job groups in the openQA test overview page already is supported.
Some feedback regarding changes to o3: riafarov: the main concerns are around ttm, which does not (yet) cope with it as well as having to check multiple groups to find out why a snapshot can't be published - from that PoV, the split is a 'bad thing(tm)' riafarov, while I don't object, I would be nervous about the impact this split will have on the broader audience of visitors to openqa.opensuse.org - will the job groups be split and named appropriately that they'll make sense to joe on the street? How will they know which jobgroups are relevant to the release process, and which ones aren't? riafarov, right now it's relatively easy.. only the openSUSE Tumbleweed job group is relevant to the release of openSUSE Tumbleweed, for example. Kernel, aarch64, power, are not riafarov, I think it would be a prerequisite for any split that the openqa.opensuse.org webui can make it very apparent which are relevant to the release of which product riafarov, also from a Kubic perspective, I'd be very , very, very, interested in how you'd split that. It is absolutely imperative, as part of the very existence of the Kubic project, that it's testing is integrated as part of the TW release process. and I do not want to have to check two places for it's status