new d3d9/device.ok test always fails here, but not a regression?

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

> Bugs in newly added code cannot be regressions.
>
> Similarly, if we add a dll and some app starts using it and breaks,
> technically that's not a regression even though the behavior got worse,
> because it has always been broken, it just wasn't exercised before.

What does this distinction bring us?  The old definition, "if it
worked in version N and doesn't in N+1, then it is a regression" was
straightforward and easy to understand.  There was little to debate,
no room left for confusion.  Every such regression could be associated
with the SHA1 of a commit.

The new definition can get arbitrarily complex.  Consider bug #19496.
Bug resolution likely involves moving from mciwave to mciavi.  As
mciavi is not equally advanced, this move will likely cause bugs to
appear in other apps.  But we wouldn't call them regressions "because
it has always been broken"?!?  That makes no sense to users.

What benefit does it have for developers?  Having one's name appear less
often in source.winehq.org/regressions when doing The Right Thing (TRT)?

Regards,
	Jörg Höhle