On Mon, May 6, 2019 at 12:27 PM Martin Kolman <mkolman@xxxxxxxxxx> wrote: > > On Mon, 2019-05-06 at 12:09 -0600, Chris Murphy wrote: > > It is completely impractical for QA to, every cycle, do a clean > > install of each version of Fedora, and upgrade them in sequence to the > > current pre-release version, and if any of those get stuck somewhere, > > suggest it would be release blocking. It's totally untenable. > As a manual test - indeed. But as a fully automated test running in a VM it could work IMHO. To what end? Someone would have to build this test in openqa, and then when it fails, check it and try and figure out why it failed, which itself could take hours. The release criterion is clear, such a bug wouldn't block release. That a thing can be done does not mean that thing should be done. > This would presumably run for many hours, but if multiple runs could be done for different starting > versions N in parallel, it should still be short enough to gate stuf like GO/NOGO decissions. And the outcome in this particular instance would differ, how? Someone would need to create these tests in openqa, then someone needs to check the failing tests, and work out the cause of the problem. That's exactly what happened in this case. And quite a lot of such testing, including this one and the one you're proposing, when they aren't release blocking someone may not do that. There's quite a lot on QA's plate with just blockers and important freeze exception bugs. Everything else depends on available bandwidth. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
