Am 24.03.2017 um 17:26 schrieb Flávio J. Saraiva flaviojs2005@gmail.com:
If what winehq untimately cares about is not having regressions, then the best approach here is to split it into logical bits (only passing tests at the end of the patch set) and not try to minimize the changes in the parts i'm being forced to change.
This means that if one patch gets rejected then the whole set is also rejected. I guess this wouldn't be a problem?
It is a potential problem for bisects. Let's assume I am bisecting a direct3d regression in an app that also uses cmd.exe. Somewhere between the good and bad revisions for the d3d problem there is a revision where the app fails because of cmd.
That said, this sometimes happens and it's solvable with some extra work during bisects (e.g. manually applying the fix for cmd for revisions that are broken in a way I don't care). But this is one of the reasons why e.g. having a temporary build failure is a no-go.