On Thu, Apr 9, 2020 at 4:36 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
I agree that there are better ways to handle this in VMs, but I'm not
certain it shouldn't be considered for qemu-kvm VMs, because that code
base is something completely controllable in free and open source
software. There should be no BIOS/UEFI, ACPI, kernel, or systemd bugs
that we can't fix. If it fails, it suggests a real bug somewhere.
I'd very much like this. A pure software solution that always needs to work and we can use it as a baseline for regression testing. But at the same time, if the VM suspend got broken, but it would not affect real hardware, I have no doubts its release blocking status would quickly be demoted at a blocker review meeting. Because blocking on it makes sense from QA perspective, but not from Fedora release perspective. So I don't think this is a viable approach.
But
I'd also ask whether that's also practical, maybe ask the kernel team.
That would be my other concern. This requires a lot of expertise in multiple very low level areas. And the fact that it currently *doesn't* work for VMs suggests that it is not a priority for people who have these skills.
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
