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

[Frédéric Delanoy]

On Tue, Jan 3, 2012 at 13:01, Alexandre Julliard <julliard at winehq.org> wrote:
> Joerg-Cyril.Hoehle at t-systems.com writes:
>>
>> 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)?
>
> Yes, it reduces the noise to let you concentrate on the real
> regressions, i.e. the ones where working code got broken, and where you
> can get useful information from the previous state.
>
> Having a new piece of code tagged a regression is just noise, there's
> nothing you can do with that information. All it tells you is that the
> bug in that new code wasn't present when the code didn't exist (doh).
>
> The primary goal of Bugzilla should be to present information in a way
> that makes it easier for developers to fix bugs. A simple "my app got
> broken" flag may be easier to understand for users, but it's less
> useful.

Might be difficult to explain to "plain" users though. Some already
struggle performing a regression test (most won't even bother), let
alone understanding the fine details of what a regression really
represents.

http://wiki.winehq.org/RegressionTesting states "Sometimes, committing
patches in Wine to fix bugs and introduce new features causes new
problems. This is called a regression"

As users (and not only devs) are allowed to submit bug reports, and
they/most don't have a clue whether an app did work/doesn't anymore is
due to a new feature or not, maybe we have some additional field,
visible by default only to people with "advanced" permissions in
bugzilla, that indicates it's really a regression or not (we shouldn't
discourage users to provide a commit ID which can be useful anyway) ?

This would allow devs to concentrate to the real regressions, as you explained.

Frédéric