quite a lot of the tables have 'i386' and 'x86_64' as environments.
Especially with the Milestone column, listing i386 alongside x86_64 is
a bit misleading if i386 is no longer blocking. I can see a few
1) just ditch the i386 columns entirely; openQA can continue testing
it, and people can test manually if they want, but we don't bother
tracking the results in the validation pages
2) stick an admon template at the top of the page saying 'the i386
tests aren't blocking', with links out to the criteria and/or the FESCo
3) Duplicate each table which distinguishes between 'i386' and
'x86_64', so we have one table with just an 'i386' column and all tests
marked Optional, and another table with the other columns and the
I think the answer here is largely dependent on what we want to do about OpenQA. If we
didn't have OpenQA at all, I'd do #1, and I'd also duplicate Workstation* and
Server* rows in "Default boot and install" section, gray out x86_64 and UEFI
columns, and mark the rows as optional. Therefore i686 would be handled the same way we
handle spins - there's a way to mark a critical error which prevents default install
and boot in the matrix, but that's it.
The same solution would probably apply if we decided to drop i686 testing from OpenQA.
But if we want to still test i686 in OpenQA (at least on a best-effort basis), we somewhat
rely on the wiki pages for reporting. (Or do you think that having it in OpenQA frontend
is good enough?).
So if we want to keep the matrices around for that purpose, I'd either do #3 and
collapse them by default, or I'd create a separate wiki page just for i686 and direct
OpenQA results there. This way we can still easily see what was and what wasn't
tested, and tools like testcase_stats work for it, but we the core wiki matrices are not
overflowing with non-essential stuff. But it is some work and maintenance, and I'm not
sure it's worth it. Maybe the OpenQA frontend is just good enough?