Hey all,
As is tradition, on Saturday I plan to review the winehq test regime, and pound my fist on the table until people commit to fixing tests.
We've spent the past few years managing the transition to qemu. I've been using this page to triage that progress:
https://www.winehq.org/~jwhite/latest.html
That reflects issues with our tests on Windows on qemu, excluding Windows 8 and Windows 10 (although it looks like I could perhaps add Windows 8 back into the mix, as the bleeding does not seem that bad any longer).
We've stalled out at about 13 issues; we don't seem to be able to get below that. (There are 8 'old' issues, and 5 new ones, in case anyone wants to go look, including ones from ddraw, kernel32, netapi32, and user32).
Prior to the qemu drive, the original goal was to get at least one Linux machine known to run the tests cleanly. The further hope would be that if we had a known set of 'good' test machines, then we could require that every patch succeed when run on those machines.
We've made sporadic progress on that, but we did purchase a set of hardware with the intent of making that hardware run those tests cleanly.
I see that we've driven those down to about 20 per system. Those machines are 'portable', for generous definitions of portable. But we could bring one or both them to Wineconf and work directly on them if we liked. Would that be useful?
And, more broadly, is there some other way to consider this that would be more useful? Is there useful prep we can do that will give way to more constructive sessions at Wineconf?
Cheers,
Jeremy