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
2016-11-07 8:47 GMT-07:00 Jeremy White jwhite@codeweavers.com:
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
That's great news! I am curious to see how many of these Linux failures are reproducible on common Linux setups.
The failing Windows tests are going to be complicated to fix. I could pick one and take a crack at it, but I'm not really excited about sending patches for complicated bugs when I send patches for simple bugs and I get the silent treatment. If I knew that my patches would be given fair consideration, I would try to fix some of the test failures.
Despite the improvements that were made after last year's WineConf, I still feel frustrated about wanting to contribute and finding myself unable to. And I feel bad saying that because Alexandre does most patch reviews, and he has already put so much of his life into Wine. It's a great project--Alexandre, we all love you for it! There's got to be a way for us to work together better.
-Alex