Hi Dmitry,
And another rule is that the patch which changes the behaviour of an API needs to have an appropriate test case which does not pass before the patch (i.e. has the todo_wine around it), and passes after the patch (i.e. the patch removes the corresponding todo_wine). Your patch doesn't qualify for that.
I think this is a good guideline, but I think Joerg justified his approach reasonably well: his first attempt introduced a test failure because it caused a previously spuriously passing test to fail. His choices are to resubmit this patch, marking the test todo_wine along with an explanation, and follow up with the patch that really fixes the test, or to submit the two combined. I think both are reasonable if the explanation is clear enough.
The rule clearly applies when a test was not spuriously passing before, e.g. is marked todo_wine, but in cases when the test is spuriously passing, the "tests must always pass" rule also comes into play. The tests must always pass rule takes precedence, making the tests should only ever remove a todo_wine rule impossible to meet. --Juan