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

Alexandre Julliard julliard at winehq.org
Tue Jan 3 06:01:19 CST 2012


Joerg-Cyril.Hoehle at t-systems.com writes:

> 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)?

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.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list