The patches will always build, the tests are what will fail (will need the full patch set). To avoid the temporary failure of tests the patch set needs to be applied in one go (commit to a separate branch and then merge to master?), but that's out of my hands. I got "Needs splitting" so that's what i'll do, and this time I won't try to minimize changes to other code (and therefore avoid adding hacks).
Flávio J. Saraiva
2017-03-25 10:58 GMT+00:00 Stefan Dösinger stefandoesinger@gmail.com:
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.