On Wed, Aug 30, 2017 at 07:57:39AM -0400, Adam Williamson wrote:
Not sure specifically what I can contribute, but please do say a bit
more precisely what you think I could help with and I'll do my best to
either provide answers/help or point you to someone more useful than
AFAIK there are no formal functionality requirements for non-release-
blocking arches...really anywhere. You can obviously use the release
criteria that apply to release-blocking arches as a general guide to
what a 'working Fedora' looks like, but you aren't required by any
process to fully meet them at any point.
We do run automated testing of i686 composes in openQA, and packages in
Taskotron. The openQA tests are run on x86_64 VMs, however; we ran them
on emulated 32-bit VMs for a while but ran into several problems there
which were apparently specific to the qemu/kvm emulation of a 32-bit
CPU (qemu32) and were told it's a path that isn't heavily supported by
the virt folks, so we stopped doing that. We also don't run anywhere
close to the *whole* set of tests on i686, mainly because we don't have
enough worker capacity to do that. We run a subset of key tests.
I don't believe the Red Hat Fedora QA team has any non-x64 testing
hardware in our regular inventory, but it's likely that some Fedora QA
Just as a general note, although it's kinda obvious and you may well
have thought of it already, I would suggest talking to the other
currently-active and organized non-blocking arch groups about their
process and see what you can crib. The ppc64 group in particular is
Thanks for taking the time to respond!
Contacting the ppc64 group is a great suggestion. I'll try to touch base with them.
Thanks for so much information. Very helpful. The automated tests, are they easy to
automate on actual hardware? or do key parts of the automated tests sit outside of the
It sounds to me like the best ways the SIG can help QA is:
* Be a primary resource (hardware and warm bodies) for debugging i686-related boot,
kernel, driver, and instruction-set related issues
* Help with testing
* Help triage all other i686-related issues in Bugzilla
* more testing!
Are there any additional critical shortfalls? I know there is no shortage of ways we can
help, but I want to start with the severe needs first.