For what it's worth, the idea at the time was that the process would go something like this:
* We investigate a test failure, and it turns out it's an upstream driver bug. * We report/fix that bug upstream, and a driver fix gets committed. * We add a "bug_if(is\_<vendor>\_device(device, "<version>"))" to the tests and wait for the fixed version to be sufficiently propagated. In practice that would probably be until it's in Debian stable. * We remove the bug_if() again.
The workflow makes sense, but I kind of fail to understand why to use "bug_if(...)" instead of "todo_wine_if(...)", except for I guess a bit of extra code clarity. But my other concern about bug(), as it is, is that before step 4 happens, the bug will be forgotten about. And because the tests now succeed either way, nobody will notice when the fixed version *does* hit repositories. My idea is to introduce some more stringent tracking that will, among other things, make sure that tests will start "failing" once the bug is fixed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3565#note_43364