On Thu, Oct 29, 2026 at 09:14:21AM -0800, Pierrick Bouvier wrote: > On 10/29/2026 9:05 AM, Thomas Huth wrote: > > On 29/10/2026 17.38, Peter Maydell wrote: > >> On Thu, 29 Oct 2026 at 16:13, Alex Bennée <[email protected]> wrote: > >>> > >>> The full quanta_gsj test would have caught the regression caused by > >>> the WFxT implementation and isn't that slow (<60s) it needs to be > >>> gated. > >>> > >>> Suggested-by: Thomas Huth <[email protected]> > >>> Signed-off-by: Alex Bennée <[email protected]> > >>> --- > > ... > >> The other argument against using quanta-gsj as our test here > >> is that as discussed as part of a recent docs update: > >> https://lore.kernel.org/qemu-devel/20260627063208.33642-1- > >> [email protected]/ > >> it's no longer supported by OpenBMC. > >> > >> I didn't get any response from the Nuvoton maintainers in > >> that thread, but I kind of favour deprecating the machine > >> type in QEMU. > > If nobody seems to care anymore, please go ahead and mark it as > > deprecated! We can still revert it in case someone speaks up later > > during the deprecation period. > > > > Thomas > > > > > > For what it's worth, I also noticed that this test tends to timeout > randomly, even when running tests with -j1. So we might observe this in > our CI also, by enabling it by default.
If it is unreliable then it should be tagged with skipFlakyTest, and a gitlab issue filed with an example failure trace. If no one steps up to fix the flaky test in a reasonable time then it should later be deleted, as flaky tests should not be allowed to linger for years. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
