Re: do ERR messages imply bugs?

[chris ahrendt]

Ben Klein wrote:

2009/4/13 chris ahrendt :
  

Is there a guide documenting what each test is supposed to do etc?



Source code.

Before you say that's an unacceptable answer, the sheer number of test
cases (especially considering those that keep getting added) would
make it impractical to the point of impossibility to maintain proper
documentation on each test. And when the tests are only intended for
developers anyway, the source code is perfectly suitable as
documentation. The tests are relatively simple, and it's clear which
case is being test by the use of ok().

  

I run the test set to see where the current version of wine is on any of my
particular hardware.



Then you should learn to interpret the ERRs correctly.

  

I am not allowed to develop wine due to NDA's , and so forth I am under. And
have discussed
with the Alexandre and Dan concerning these NDA's and what I can do to help.



That does not make any sense...  There has to be a consistent way for
developers and users
to report or work on issues..



It's called bugzilla.

  

I believe you may be missing my point Ben. By consistent I mean an ERR means
this and only means this. Warning, info etc...



As far as I'm concerned, that already exists, even if it's not written
explicitly and finitely in the dev guide. ERRs caused by the test
suite can be ignored as long as the tests run correctly. By the same
logic, ERRs caused by real applications can be ignored as long as the
apps still run correctly. In the former case, there is no motivation
for the devs to fix them. In the latter, there is minimal motivation,
and the devs have bigger problems to worry about than things that
aren't actually *breaking* anything at the moment.

  

From what I  have been following here and also seeing in the code an error
doesn't always follow the
coding standard set forth in the developers guide.



I don't think you understand the nature of the test suite. There are
some tests that are 100% valid logic and are expected to create no
ERRs or WARNs. These are called positive cases. There are some tests
that are not 100% valid logic, and do things wrong deliberately, and
are expected to create both ERRs and WARNs. That's an "and" there, not
an "or". Both ERRs and WARNs. This cannot change.

  

and like Vincent says the use has gotten a little skewed.


Or been misinterpreted ... though a review of the developers' guide
description of ERR wouldn't hurt.

  

I would agree it may be... and maybe a review is in order..



So who wants to volunteer? :)


  

Not I =)



2009/4/13 chris ahrendt :
  

An Excellent point was mad in one of the bugs I reported :

Comment #25 from Austin English 

The problem is that this isn't a 'normal' application doing weird things.
It's our testsuite, which does some _really_ strange stuff, e.g., lots of
corner case testing.
Our implementation code, however, knows this is weird, and prints an error.
The problem is that there's no way to tell, e.g, dlls/mshtml/htmldoc.c that
what's
being tested is dlls/mshtml/tests/doc.c, rather than foobar.exe. It's a bit
misleading, which makes it a bit harder for users.



This is EXACTLY what I've been saying. You ignore me, and listen to
Austin. Absolutely fantastic.

  
not AT All ben =D  I do and have understood that there are positive and 
negative test cases.
The point I guess I am trying to make is in the test cases where there 
is an expected failure just

print something out saying this is expected. Not Complicated at all.

So, there has to be a happy middle in this...
why not have in the test suite some printf or the like that says to the
effect that err output is to be expected or the like.. Most users if they
see ERROR on the screen
be it in a test case or an application will think its a bug and not just
ignore it.



Most users DON'T RUN THE TEST SUITE. It's not useful for users, it's
ONLY useful for developers, and developers know how to interpret these
ERRs correctly. You don't.
  


Thanks for the attack ben... again you miss the point.. alot more users 
do run the tests than you may think.
People evaluating the code for use in their enterprise will run the test 
sets.. and if they don't complete or run

clean than they don't implement.

C

Re: do ERR messages imply bugs?

[chris ahrendt]

An Excellent point was mad in one of the bugs I reported :

Comment #25 from Austin English 

The problem is that this isn't a 'normal' application doing weird 
things. It's our testsuite, which does some _really_ strange stuff, 
e.g., lots of corner case testing.
Our implementation code, however, knows this is weird, and prints an 
error. The problem is that there's no way to tell, e.g, 
dlls/mshtml/htmldoc.c that what's
being tested is dlls/mshtml/tests/doc.c, rather than foobar.exe. It's a 
bit misleading, which makes it a bit harder for users.


So, there has to be a happy middle in this...
why not have in the test suite some printf or the like that says to the 
effect that err output is to be expected or the like.. Most users if 
they see ERROR on the screen
be it in a test case or an application will think its a bug and not just 
ignore it.



Chris

Re: do ERR messages imply bugs?

[chris ahrendt]

Ben Klein wrote:

2009/4/13 chris ahrendt :
  

So basically it, in your opinion, comes down to ERR's and the debug output
from running
tests or anything else should be ignored by anyone but developers?



No, that the tests as a WHOLE should be ignored by everyone except developers.

  

Is there a guide documenting what each test is supposed to do etc?
I run the test set to see where the current version of wine is on any of 
my particular hardware.
I am not allowed to develop wine due to NDA's , and so forth I am under. 
And have discussed
with the Alexandre and Dan concerning these NDA's and what I can do to 
help.

That does not make any sense...  There has to be a consistent way for
developers and users
to report or work on issues..



It's called bugzilla.
  
I believe you may be missing my point Ben. By consistent I mean an ERR 
means this and only means this. Warning, info etc...
From what I  have been following here and also seeing in the code an 
error doesn't always follow the

coding standard set forth in the developers guide.
  

and like Vincent says the use has gotten a little skewed.



Or been misinterpreted ... though a review of the developers' guide
description of ERR wouldn't hurt.
  


I would agree it may be... and maybe a review is in order..

chris

Re: do ERR messages imply bugs?

[chris ahrendt]

Ben Klein wrote:

2009/4/13 James McKenzie :
  

Ben Klein wrote:


2009/4/13 chris ahrendt :

  

Vincent Povirk wrote:



On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein  wrote:

  

2009/4/13 Vincent Povirk :



But the description doesn't say "invalid conditions". It says "serious
errors in Wine". That's something that should never happen in tests,
as it would imply that the state of the libraries we're testing (and
thus the test) is invalid.

  

How about "serious errors in Wine, or in the test cases, sometimes
deliberate errors in the tests"? As Vitaliy points out, some tests
deliberately do invalid things to make sure they fail. We can't ONLY
test on things that succeed!



I'm not against changing the description. If it's OK to have err
messages for cases that we know fail (but don't crash or prevent the
library from continuing to function), then the Developer's Guide is
wrong and should be changed. I also don't care how long it takes to
make the change, as long as there's a consensus that it's the guide
that's wrong and not the reality of what's in Wine.

  

This is EXACTLY the point I am trying to get to.. if they are normal and not
ERRORS but warnings then they should be thus and noted in the developers
guide. Right now Wine isn't even following its own guidelines in this case.



No. Not warnings. Errors. They are errors. There is no way to
distinguish an error caused by a real application from an error caused
by a Wine test.


  

If the situation is an error and it is expected, the test should handle
this, like:

ok (some_test_here_that_should_fail, "The test that should fail, did/n")

I'm guessing that most of the tests that should fail, do.  I don't know
if there is a failure like there is an ok.



AFAIK, this is how expected failures in tests are handled. I saw a few
recent tests submitted and/or committed that do it like this.

  

If you don't like it, run all your tests with WINEDEBUG=-all.



  

And that will prove nothing.  Tests should be run with debugging on.
You are really being sarcastic, right?

As to the discussion, I will add my .02 Eurocent here:

Fixme:  Code that is not implemented that should be.
Warning:  Code that encountered an unexpected or new condition that is
not normal.  Data should not be corrupted by this event.
Error:  Code encountered a condition that will result in corruption of data.
It appears that we have 'error creep' and that is not good from a user
point of view and it is really irritating from a support point of view.

During testing an error could be either a Warning or an Error.  Tests
should not be run against non-existent Wine code, but should against
existing Windows code.  The situation with testing is that unexpected or
improper behavior of code should be an error.  There is no such thing as
a warning during a test run.  Either the test passes, which means that
Wine is acting the same as a certain version of Windows, or it is not.



There is no way for the Wine components that are producing the errors
to distinguish between a test run and a real application. Again, the
tests are triggering these errors not in the test applications but in
other Wine components. In some (possibly all) cases that this happens,
this is expected and correct (because it is impossible to distinguish
between a genuine error and a test error).

  

Now, the problem is that we are sending cryptic messages to end users,
most of which they can and should ignore.  Err messages piling up on
their terminal windows should be a cause for concern.  If we know that a
condition does not cause data corruption, then we should not be marking
it as an error, but maybe a warning or if the code is non-existent or
improper, a fixme.



End users shouldn't be running the tests without understanding how they work.

  

Can we start to clean up some of the most obvious "it is not an error
but the message says it is" so that we can calm down users who encounter
them?



The ERRs are being produced by components of Wine outside the test
cases. It's highly likely for those ERRs to change in later versions
of Wine. If you want to maintain a complete list of where ERRs will be
triggered by test cases and include a message for each one that says
"It's OK, you can ignore this ERR", then I'm sure you're welcome to
try it.

2009/4/13 James McKenzie :
  

Vitaliy Margolen wrote:


You wrong. As I said, tests are _allowed_ and some really _supposed to_ test
invalid cases. Where Wine 100% correct about complaining. But the goal of
each test is either succeed or fail. If it succeeds then there is no bug.

  

Conversely, if a good test starts to fail or error messages appear where
there were none, we have a problem that needs to be reported so it can
be fixed (this happened with Wine 1.1.18).



There is a BIG difference between "test caused an ERR message" and
"test failed". They are handled d

Re: do ERR messages imply bugs?

[chris ahrendt]

Vincent Povirk wrote:

On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein  wrote:

2009/4/13 Vincent Povirk :

But the description doesn't say "invalid conditions". It says "serious
errors in Wine". That's something that should never happen in tests,
as it would imply that the state of the libraries we're testing (and
thus the test) is invalid.

How about "serious errors in Wine, or in the test cases, sometimes
deliberate errors in the tests"? As Vitaliy points out, some tests
deliberately do invalid things to make sure they fail. We can't ONLY
test on things that succeed!


I'm not against changing the description. If it's OK to have err
messages for cases that we know fail (but don't crash or prevent the
library from continuing to function), then the Developer's Guide is
wrong and should be changed. I also don't care how long it takes to
make the change, as long as there's a consensus that it's the guide
that's wrong and not the reality of what's in Wine.


This is EXACTLY the point I am trying to get to.. if they are normal and 
not

ERRORS but warnings then they should be thus and noted in the developers
guide. Right now Wine isn't even following its own guidelines in this case.


Chris

Re: do ERR messages imply bugs?

[chris ahrendt]

Vitaliy Margolen wrote:

chris ahrendt wrote:
  

17997 Gecko is installed and reran test... same result... valid bug

17998 is the locking issue... and it occurs not just in the rest but in
another application as well..



What errors? What exactly isn't working for you? You have failed to explain
that. Until you meaningfully can explain everyone what isn't working for
you? What exact applications are you having problems with? Where are they
failed tests you are speaking of, these bugs invalid!

DO NOT REOPEN THEM!

Vitaliy.
  
THe ERR  mesages which are in the logs I uloaded. As pointed out in the 
wine development logs
an ERR is only supposed to happen if something goes wrong or is not 
working correctly.
So either these are warning messages and need to be changed as such or 
they are actual failures in the underlying code

and will need to get fixed.

If the action is normal for the failure in the test case then it should 
be output on the screen somewhere in the log stating this is normal.


Chris

Re: do ERR messages imply bugs?

[chris ahrendt]

Vitaliy Margolen wrote:

Vincent Povirk wrote:
  

Chris Ahrendt filed a few bugs recently for "err" messages encountered
during test runs  (17997 and 17998 at least).



17997 is a bogus report - Gecko is not intalled. Nothing actually failed.
17998 is the same. Only I let our resident 3D gurus to respond. I don't see
any problems with tests testing invalid conditions. This most likely one of
those cases.

If Chris doesn't like err messages, he can shut them off.

Vitaliy.
  

17997 Gecko is installed and reran test... same result... valid bug

17998 is the locking issue... and it occurs not just in the rest but in 
another application as well..

Re: do ERR messages imply bugs?

[Vitaliy Margolen]

James McKenzie wrote:
> We are not 'wasting time.'  This issue needs to be addressed by the
> development community so that errors, warnings and fixmes are properly
> reported.
This is semantics. FIXME/WARN/ERR - who cares? They are all just hints if
something goes wrong where to look.

Each developer uses them differently. If you suggesting we all drop all we
are doing and change all ERR(), that not really errors, but some messages
that can happen even with broken windows programs, to WARN(), since FIXME()
doesn't really qualify because this feature in most cases is implemented.
Then we should just shut all the messages off by default and get rid of
them. Or do s/ERR/WARN/g on the whole codebase.

Keep in mind lots and lots of windows programs trigger errors, because of
bugs in their code. That happens on windows to. So because of some crappy
program we want to limit ourself to what we can see? How does that help with
troubleshooting valid errors? Or you want ask users for +all log every time
something doesn't work?

Vitaliy.

Re: do ERR messages imply bugs?

[Ben Klein]

2009/4/13 chris ahrendt :
> Ben Klein wrote:
>> Most users DON'T RUN THE TEST SUITE. It's not useful for users, it's
>> ONLY useful for developers, and developers know how to interpret these
>> ERRs correctly. You don't.
>>
>
> Thanks for the attack ben... again you miss the point.. alot more users do
> run the tests than you may think.

Then they need to learn to interpret them correctly.

> People evaluating the code for use in their enterprise will run the test
> sets.. and if they don't complete or run
> clean than they don't implement.

Their problem. If they refuse to implement Wine in their enterprise
solutions because Wine's test suites produces ERRs, this is their
problem, not ours.

I'd also argue against using Wine at enterprise level. Crossover would
probably be a better solution when it comes to businesses, with paid
tech support and a more business-oriented user interface.

Re: do ERR messages imply bugs?

[Ben Klein]

2009/4/13 chris ahrendt :
> Is there a guide documenting what each test is supposed to do etc?

Source code.

Before you say that's an unacceptable answer, the sheer number of test
cases (especially considering those that keep getting added) would
make it impractical to the point of impossibility to maintain proper
documentation on each test. And when the tests are only intended for
developers anyway, the source code is perfectly suitable as
documentation. The tests are relatively simple, and it's clear which
case is being test by the use of ok().

> I run the test set to see where the current version of wine is on any of my
> particular hardware.

Then you should learn to interpret the ERRs correctly.

> I am not allowed to develop wine due to NDA's , and so forth I am under. And
> have discussed
> with the Alexandre and Dan concerning these NDA's and what I can do to help.
>
>>>
>>> That does not make any sense...  There has to be a consistent way for
>>> developers and users
>>> to report or work on issues..
>>>
>>
>> It's called bugzilla.
>>
>
> I believe you may be missing my point Ben. By consistent I mean an ERR means
> this and only means this. Warning, info etc...

As far as I'm concerned, that already exists, even if it's not written
explicitly and finitely in the dev guide. ERRs caused by the test
suite can be ignored as long as the tests run correctly. By the same
logic, ERRs caused by real applications can be ignored as long as the
apps still run correctly. In the former case, there is no motivation
for the devs to fix them. In the latter, there is minimal motivation,
and the devs have bigger problems to worry about than things that
aren't actually *breaking* anything at the moment.

> From what I  have been following here and also seeing in the code an error
> doesn't always follow the
> coding standard set forth in the developers guide.

I don't think you understand the nature of the test suite. There are
some tests that are 100% valid logic and are expected to create no
ERRs or WARNs. These are called positive cases. There are some tests
that are not 100% valid logic, and do things wrong deliberately, and
are expected to create both ERRs and WARNs. That's an "and" there, not
an "or". Both ERRs and WARNs. This cannot change.

>>> and like Vincent says the use has gotten a little skewed.
>>
>> Or been misinterpreted ... though a review of the developers' guide
>> description of ERR wouldn't hurt.
>>
>
> I would agree it may be... and maybe a review is in order..

So who wants to volunteer? :)


2009/4/13 chris ahrendt :
> An Excellent point was mad in one of the bugs I reported :
>
> Comment #25 from Austin English 
>
> The problem is that this isn't a 'normal' application doing weird things.
> It's our testsuite, which does some _really_ strange stuff, e.g., lots of
> corner case testing.
> Our implementation code, however, knows this is weird, and prints an error.
> The problem is that there's no way to tell, e.g, dlls/mshtml/htmldoc.c that
> what's
> being tested is dlls/mshtml/tests/doc.c, rather than foobar.exe. It's a bit
> misleading, which makes it a bit harder for users.

This is EXACTLY what I've been saying. You ignore me, and listen to
Austin. Absolutely fantastic.

> So, there has to be a happy middle in this...
> why not have in the test suite some printf or the like that says to the
> effect that err output is to be expected or the like.. Most users if they
> see ERROR on the screen
> be it in a test case or an application will think its a bug and not just
> ignore it.

Most users DON'T RUN THE TEST SUITE. It's not useful for users, it's
ONLY useful for developers, and developers know how to interpret these
ERRs correctly. You don't.

Re: do ERR messages imply bugs?

[Ben Klein]

2009/4/13 chris ahrendt :
> So basically it, in your opinion, comes down to ERR's and the debug output
> from running
> tests or anything else should be ignored by anyone but developers?

No, that the tests as a WHOLE should be ignored by everyone except developers.

> That does not make any sense...  There has to be a consistent way for
> developers and users
> to report or work on issues..

It's called bugzilla.

> and like Vincent says the use has gotten a little skewed.

Or been misinterpreted ... though a review of the developers' guide
description of ERR wouldn't hurt.

Re: do ERR messages imply bugs?

[Ben Klein]

2009/4/13 James McKenzie :
> Ben Klein wrote:
>> 2009/4/13 chris ahrendt :
>>
>>> Vincent Povirk wrote:
>>>
 On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein  wrote:

> 2009/4/13 Vincent Povirk :
>
>> But the description doesn't say "invalid conditions". It says "serious
>> errors in Wine". That's something that should never happen in tests,
>> as it would imply that the state of the libraries we're testing (and
>> thus the test) is invalid.
>>
> How about "serious errors in Wine, or in the test cases, sometimes
> deliberate errors in the tests"? As Vitaliy points out, some tests
> deliberately do invalid things to make sure they fail. We can't ONLY
> test on things that succeed!
>
 I'm not against changing the description. If it's OK to have err
 messages for cases that we know fail (but don't crash or prevent the
 library from continuing to function), then the Developer's Guide is
 wrong and should be changed. I also don't care how long it takes to
 make the change, as long as there's a consensus that it's the guide
 that's wrong and not the reality of what's in Wine.

>>> This is EXACTLY the point I am trying to get to.. if they are normal and not
>>> ERRORS but warnings then they should be thus and noted in the developers
>>> guide. Right now Wine isn't even following its own guidelines in this case.
>>>
>>
>> No. Not warnings. Errors. They are errors. There is no way to
>> distinguish an error caused by a real application from an error caused
>> by a Wine test.
>>
>>
> If the situation is an error and it is expected, the test should handle
> this, like:
>
> ok (some_test_here_that_should_fail, "The test that should fail, did/n")
>
> I'm guessing that most of the tests that should fail, do.  I don't know
> if there is a failure like there is an ok.

AFAIK, this is how expected failures in tests are handled. I saw a few
recent tests submitted and/or committed that do it like this.

>> If you don't like it, run all your tests with WINEDEBUG=-all.
>>
>>
>>
> And that will prove nothing.  Tests should be run with debugging on.
> You are really being sarcastic, right?
>
> As to the discussion, I will add my .02 Eurocent here:
>
> Fixme:  Code that is not implemented that should be.
> Warning:  Code that encountered an unexpected or new condition that is
> not normal.  Data should not be corrupted by this event.
> Error:  Code encountered a condition that will result in corruption of data.
> It appears that we have 'error creep' and that is not good from a user
> point of view and it is really irritating from a support point of view.
>
> During testing an error could be either a Warning or an Error.  Tests
> should not be run against non-existent Wine code, but should against
> existing Windows code.  The situation with testing is that unexpected or
> improper behavior of code should be an error.  There is no such thing as
> a warning during a test run.  Either the test passes, which means that
> Wine is acting the same as a certain version of Windows, or it is not.

There is no way for the Wine components that are producing the errors
to distinguish between a test run and a real application. Again, the
tests are triggering these errors not in the test applications but in
other Wine components. In some (possibly all) cases that this happens,
this is expected and correct (because it is impossible to distinguish
between a genuine error and a test error).

> Now, the problem is that we are sending cryptic messages to end users,
> most of which they can and should ignore.  Err messages piling up on
> their terminal windows should be a cause for concern.  If we know that a
> condition does not cause data corruption, then we should not be marking
> it as an error, but maybe a warning or if the code is non-existent or
> improper, a fixme.

End users shouldn't be running the tests without understanding how they work.

> Can we start to clean up some of the most obvious "it is not an error
> but the message says it is" so that we can calm down users who encounter
> them?

The ERRs are being produced by components of Wine outside the test
cases. It's highly likely for those ERRs to change in later versions
of Wine. If you want to maintain a complete list of where ERRs will be
triggered by test cases and include a message for each one that says
"It's OK, you can ignore this ERR", then I'm sure you're welcome to
try it.

2009/4/13 James McKenzie :
> Vitaliy Margolen wrote:
>> You wrong. As I said, tests are _allowed_ and some really _supposed to_ test
>> invalid cases. Where Wine 100% correct about complaining. But the goal of
>> each test is either succeed or fail. If it succeeds then there is no bug.
>>
>
> Conversely, if a good test starts to fail or error messages appear where
> there were none, we have a problem that needs to be reported so it can
> be fixed (this happened with Wine 1.1.18).

There is a BIG difference between "test caused

Re: do ERR messages imply bugs?

[James McKenzie]

Vitaliy Margolen wrote:
> chris ahrendt wrote:
>   
>> Vitaliy Margolen wrote:
>> 
>>> chris ahrendt wrote:
>>>  
>>>   
 17997 Gecko is installed and reran test... same result... valid bug

 17998 is the locking issue... and it occurs not just in the rest but in
 another application as well..
 
 
>>> What errors? What exactly isn't working for you? You have failed to
>>> explain
>>> that. Until you meaningfully can explain everyone what isn't working for
>>> you? What exact applications are you having problems with? Where are they
>>> failed tests you are speaking of, these bugs invalid!
>>>
>>> DO NOT REOPEN THEM!
>>>
>>> Vitaliy.
>>>   
>>>   
>> THe ERR  mesages which are in the logs I uloaded. As pointed out in the
>> wine development logs
>> an ERR is only supposed to happen if something goes wrong or is not
>> working correctly.
>> So either these are warning messages and need to be changed as such or
>> they are actual failures in the underlying code
>> and will need to get fixed.
>>
>> If the action is normal for the failure in the test case then it should
>> be output on the screen somewhere in the log stating this is normal.
>> 
>
> You wrong. As I said, tests are _allowed_ and some really _supposed to_ test
> invalid cases. Where Wine 100% correct about complaining. But the goal of
> each test is either succeed or fail. If it succeeds then there is no bug.
>   

Conversely, if a good test starts to fail or error messages appear where
there were none, we have a problem that needs to be reported so it can
be fixed (this happened with Wine 1.1.18).
> Again there are not failures in the tests your ran! There is nothing to fix
> here. Move along don't waste everyone time for something YOU DO NOT LIKE! Or
> send patches.
>   

The problem is that error messages should not appear where there are no
errors.  They should be either warnings or fixmes.  If the test passes
but a bunch of error messages appear during the test run, there is a
coding problem that needs to be fixed.  This is why we are answering
user questions with 'The error message can be ignored, there is nothing
wrong with the execution of your program.'  This makes it appear that
the developers don't know what they are doing and that makes the overall
project appear bad. 
>
> Conversation is over. DO NOT WASTE everyone's time!!!
>
>   
We are not 'wasting time.'  This issue needs to be addressed by the
development community so that errors, warnings and fixmes are properly
reported.  We can and maybe should get more granular when we work with
code.  Maybe a fixme for a known but unimplemented function and a
warning for an incomplete function.  Maybe changing the wording on an
error message that really is an error in code but will not cause a
program to crash.  I've seen error messages that really should be fixmes
and the other way around where a fixme causes some programs to terminate
with a screen full of debugging code.

James McKenzie

> Vitaliy
>
>
>
>   

Re: do ERR messages imply bugs?

[James McKenzie]

Ben Klein wrote:
> 2009/4/13 chris ahrendt :
>   
>> Vincent Povirk wrote:
>> 
>>> On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein  wrote:
>>>   
 2009/4/13 Vincent Povirk :
 
> But the description doesn't say "invalid conditions". It says "serious
> errors in Wine". That's something that should never happen in tests,
> as it would imply that the state of the libraries we're testing (and
> thus the test) is invalid.
>   
 How about "serious errors in Wine, or in the test cases, sometimes
 deliberate errors in the tests"? As Vitaliy points out, some tests
 deliberately do invalid things to make sure they fail. We can't ONLY
 test on things that succeed!
 
>>> I'm not against changing the description. If it's OK to have err
>>> messages for cases that we know fail (but don't crash or prevent the
>>> library from continuing to function), then the Developer's Guide is
>>> wrong and should be changed. I also don't care how long it takes to
>>> make the change, as long as there's a consensus that it's the guide
>>> that's wrong and not the reality of what's in Wine.
>>>   
>> This is EXACTLY the point I am trying to get to.. if they are normal and not
>> ERRORS but warnings then they should be thus and noted in the developers
>> guide. Right now Wine isn't even following its own guidelines in this case.
>> 
>
> No. Not warnings. Errors. They are errors. There is no way to
> distinguish an error caused by a real application from an error caused
> by a Wine test.
>
>   
If the situation is an error and it is expected, the test should handle
this, like:

ok (some_test_here_that_should_fail, "The test that should fail, did/n")

I'm guessing that most of the tests that should fail, do.  I don't know
if there is a failure like there is an ok. 

> If you don't like it, run all your tests with WINEDEBUG=-all.
>
>
>   
And that will prove nothing.  Tests should be run with debugging on. 
You are really being sarcastic, right?

As to the discussion, I will add my .02 Eurocent here:

Fixme:  Code that is not implemented that should be.
Warning:  Code that encountered an unexpected or new condition that is
not normal.  Data should not be corrupted by this event.
Error:  Code encountered a condition that will result in corruption of data.
It appears that we have 'error creep' and that is not good from a user
point of view and it is really irritating from a support point of view.

During testing an error could be either a Warning or an Error.  Tests
should not be run against non-existent Wine code, but should against
existing Windows code.  The situation with testing is that unexpected or
improper behavior of code should be an error.  There is no such thing as
a warning during a test run.  Either the test passes, which means that
Wine is acting the same as a certain version of Windows, or it is not.

Now, the problem is that we are sending cryptic messages to end users,
most of which they can and should ignore.  Err messages piling up on
their terminal windows should be a cause for concern.  If we know that a
condition does not cause data corruption, then we should not be marking
it as an error, but maybe a warning or if the code is non-existent or
improper, a fixme.

Can we start to clean up some of the most obvious "it is not an error
but the message says it is" so that we can calm down users who encounter
them?

James McKenzie

Re: do ERR messages imply bugs?

[Ben Klein]

2009/4/13 chris ahrendt :
> Vincent Povirk wrote:
>>
>> On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein  wrote:
>>>
>>> 2009/4/13 Vincent Povirk :

 But the description doesn't say "invalid conditions". It says "serious
 errors in Wine". That's something that should never happen in tests,
 as it would imply that the state of the libraries we're testing (and
 thus the test) is invalid.
>>>
>>> How about "serious errors in Wine, or in the test cases, sometimes
>>> deliberate errors in the tests"? As Vitaliy points out, some tests
>>> deliberately do invalid things to make sure they fail. We can't ONLY
>>> test on things that succeed!
>>
>> I'm not against changing the description. If it's OK to have err
>> messages for cases that we know fail (but don't crash or prevent the
>> library from continuing to function), then the Developer's Guide is
>> wrong and should be changed. I also don't care how long it takes to
>> make the change, as long as there's a consensus that it's the guide
>> that's wrong and not the reality of what's in Wine.
>
> This is EXACTLY the point I am trying to get to.. if they are normal and not
> ERRORS but warnings then they should be thus and noted in the developers
> guide. Right now Wine isn't even following its own guidelines in this case.

No. Not warnings. Errors. They are errors. There is no way to
distinguish an error caused by a real application from an error caused
by a Wine test.

If you don't like it, run all your tests with WINEDEBUG=-all.

Re: do ERR messages imply bugs?

[Vincent Povirk]

On Sun, Apr 12, 2009 at 5:24 PM, Ben Klein  wrote:
> 2009/4/13 Vincent Povirk :
>> But the description doesn't say "invalid conditions". It says "serious
>> errors in Wine". That's something that should never happen in tests,
>> as it would imply that the state of the libraries we're testing (and
>> thus the test) is invalid.
>
> How about "serious errors in Wine, or in the test cases, sometimes
> deliberate errors in the tests"? As Vitaliy points out, some tests
> deliberately do invalid things to make sure they fail. We can't ONLY
> test on things that succeed!

I'm not against changing the description. If it's OK to have err
messages for cases that we know fail (but don't crash or prevent the
library from continuing to function), then the Developer's Guide is
wrong and should be changed. I also don't care how long it takes to
make the change, as long as there's a consensus that it's the guide
that's wrong and not the reality of what's in Wine.

Re: do ERR messages imply bugs?

[Ben Klein]

> chris ahrendt wrote:
>
> 17997 Gecko is installed and reran test... same result... valid bug

My guess is Gecko didn't install right.

> 17998 is the locking issue... and it occurs not just in the rest but in
> another application as well..

Bug in application, not in Wine.
Application: "Lock this surface for me"
Windows: "It's already locked, mofo! Ignoring"
Wine: "It's already locked, mofo, but I don't know if that's what
you're meant to do, so I'll print an error then ignore it"

2009/4/13 Vincent Povirk :
> On Sun, Apr 12, 2009 at 3:05 PM, Vitaliy Margolen
>  wrote:
>>> I'm not sure about the opengl error. It could mean that some display
>>> driver is offering some render_type flags which I'm not handling yet.
>>> That can also cause issues.
>>>
>>> err:wgl:get_render_type_from_fbconfig Unknown render_type: 0
>>
>> This is all well and good, but I'm seeing this errors from pretty much any
>> 3D application. Not that all these 3D apps work flawlessly on Wine to begin
>> with - haven't seen one yet. But it's been a policy to ignore all messages
>> from Wine until user can show the real problem. So far no tests fail - and
>> that is the only acceptable "problems" from tests.
>
> Ok, but my point is (and I'm not saying we should necessarily do
> this), according to the Wine Developer's Guide an err is something
> that we should be concerned about, by definition. If we buy this, and
> some current err messages are often harmless, implying no loss of
> important functionality, they should be changed to some other channel.

There is no way to determine what errors can be suppressed as warnings
(or whatever) and what are actually harmful to the running of the
application. After all, they are errors!

Chris: dammit, do a Reply-to-all! Don't send your mail to the last guy
who happened to post, send it to the list too.


2009/4/13 Vincent Povirk :
> But the description doesn't say "invalid conditions". It says "serious
> errors in Wine". That's something that should never happen in tests,
> as it would imply that the state of the libraries we're testing (and
> thus the test) is invalid.

How about "serious errors in Wine, or in the test cases, sometimes
deliberate errors in the tests"? As Vitaliy points out, some tests
deliberately do invalid things to make sure they fail. We can't ONLY
test on things that succeed!

Re: do ERR messages imply bugs?

[Vincent Povirk]

On Sun, Apr 12, 2009 at 4:41 PM, Vitaliy Margolen
 wrote:
> Vincent Povirk wrote:
>> Ok, but my point is (and I'm not saying we should necessarily do
>> this), according to the Wine Developer's Guide an err is something
>> that we should be concerned about, by definition. If we buy this, and
>> some current err messages are often harmless, implying no loss of
>> important functionality, they should be changed to some other channel.
>
> For a normal App I'd almost agree with that (unless of course App does some
> invalid stuff which some do). For the test - no. Lots of tests probe border
> cases as well as invalid conditions. Wine is 100% correct to complain about
> such situations. However that's precisely what's being tested.
>
> All tests should be written to examine one thing at a time. And most are. If
> test doesn't fail, everything else is irrelevant.

But the description doesn't say "invalid conditions". It says "serious
errors in Wine". That's something that should never happen in tests,
as it would imply that the state of the libraries we're testing (and
thus the test) is invalid.

Vincent Povirk

Re: do ERR messages imply bugs?

[Vitaliy Margolen]

chris ahrendt wrote:
> Vitaliy Margolen wrote:
>> chris ahrendt wrote:
>>  
>>> 17997 Gecko is installed and reran test... same result... valid bug
>>>
>>> 17998 is the locking issue... and it occurs not just in the rest but in
>>> another application as well..
>>> 
>>
>> What errors? What exactly isn't working for you? You have failed to
>> explain
>> that. Until you meaningfully can explain everyone what isn't working for
>> you? What exact applications are you having problems with? Where are they
>> failed tests you are speaking of, these bugs invalid!
>>
>> DO NOT REOPEN THEM!
>>
>> Vitaliy.
>>   
> THe ERR  mesages which are in the logs I uloaded. As pointed out in the
> wine development logs
> an ERR is only supposed to happen if something goes wrong or is not
> working correctly.
> So either these are warning messages and need to be changed as such or
> they are actual failures in the underlying code
> and will need to get fixed.
> 
> If the action is normal for the failure in the test case then it should
> be output on the screen somewhere in the log stating this is normal.

You wrong. As I said, tests are _allowed_ and some really _supposed to_ test
invalid cases. Where Wine 100% correct about complaining. But the goal of
each test is either succeed or fail. If it succeeds then there is no bug.

Again there are not failures in the tests your ran! There is nothing to fix
here. Move along don't waste everyone time for something YOU DO NOT LIKE! Or
send patches.


Conversation is over. DO NOT WASTE everyone's time!!!

Vitaliy

Re: do ERR messages imply bugs?

[Vitaliy Margolen]

James McKenzie wrote:
> Of course, implementing the linker may be a project in itself.
It's already implemented. It only works from AppDB. It would be nice to have
it working from Bugzilla.

Vitaliy

Re: do ERR messages imply bugs?

[Vitaliy Margolen]

Vincent Povirk wrote:
> Ok, but my point is (and I'm not saying we should necessarily do
> this), according to the Wine Developer's Guide an err is something
> that we should be concerned about, by definition. If we buy this, and
> some current err messages are often harmless, implying no loss of
> important functionality, they should be changed to some other channel.

For a normal App I'd almost agree with that (unless of course App does some
invalid stuff which some do). For the test - no. Lots of tests probe border
cases as well as invalid conditions. Wine is 100% correct to complain about
such situations. However that's precisely what's being tested.

All tests should be written to examine one thing at a time. And most are. If
test doesn't fail, everything else is irrelevant.

Vitaliy

Re: do ERR messages imply bugs?

[David Gerard]

2009/4/12 James McKenzie :

> I understand your concern.  I like bug reports, I just don't like bug
> reports in a vacuum.  If we can get some of the functionality of an
> automatic Bugzilla to Applications Database linker in place this would
> make it much easier to avoid (not prevent) duplicate reports and for bug
> reports to have application entries and the other way round.  I really
> would like to see a bug report for each garbage entry in the
> Applications Database with associated terminal output and such.  This
> might give developers a push to fix a problem or implement code based
> upon the number of related problem reports and affected programs.  For
> example, if only three people report the same bug on the same program
> would it make more sense to work on a problem that has fifty
> reports/votes and it affects a dozen programs.
> Of course, implementing the linker may be a project in itself.


I suspect single user login for the various Wine websites is a similar
problem to arrange. And would facilitate such an appdb<->bugzilla
linkage helping things along rather than being another barrier.

The problem is really the various sites having been built as five or
six compeltely separate things rather than one in the first place.


- d.

Re: do ERR messages imply bugs?

[James McKenzie]

Vincent Povirk wrote:
> On Sun, Apr 12, 2009 at 3:05 PM, Vitaliy Margolen
>  wrote:
>   
> Ok, but my point is (and I'm not saying we should necessarily do
> this), according to the Wine Developer's Guide an err is something
> that we should be concerned about, by definition. If we buy this, and
> some current err messages are often harmless, implying no loss of
> important functionality, they should be changed to some other channel.
>
>   
+1.  If the report is not an error which will cause problems then it
should be something else, like a Warning that your program may not
function in the way you expect or a fixme, with a note that the
requested function is not implemented.  There are way to many error
messages that are causing concerns with our users.

James McKenzie

Re: do ERR messages imply bugs?

[James McKenzie]

David Gerard wrote:
> 2009/4/12 James McKenzie :
>
>   
>> Bugzilla should request an application name and AppDB entry number.
>> 
>
>
> Demanding an appID number will certainly keep the bug reports down,
> though at the expense of bug reporting.
>   
The idea is that not all users look into Bugzilla to see if there is a
problem and a workaround.  They sometimes look into the Applications
Database.  If we link bugs to applications this makes it easier and then
if we link bug status back to the applications database that lets folks
know the status of a bug and if it is fixed or not (there are such
things as regressions.)
> I can't see making bug reports arbitrarily more difficult as a good
> way for devs to get an idea of what's broken.
>   
I understand your concern.  I like bug reports, I just don't like bug
reports in a vacuum.  If we can get some of the functionality of an
automatic Bugzilla to Applications Database linker in place this would
make it much easier to avoid (not prevent) duplicate reports and for bug
reports to have application entries and the other way round.  I really
would like to see a bug report for each garbage entry in the
Applications Database with associated terminal output and such.  This
might give developers a push to fix a problem or implement code based
upon the number of related problem reports and affected programs.  For
example, if only three people report the same bug on the same program
would it make more sense to work on a problem that has fifty
reports/votes and it affects a dozen programs. 

Of course, implementing the linker may be a project in itself.

James McKenzie

Re: do ERR messages imply bugs?

[Vincent Povirk]

On Sun, Apr 12, 2009 at 3:05 PM, Vitaliy Margolen
 wrote:
>> I'm not sure about the opengl error. It could mean that some display
>> driver is offering some render_type flags which I'm not handling yet.
>> That can also cause issues.
>>
>> err:wgl:get_render_type_from_fbconfig Unknown render_type: 0
>
> This is all well and good, but I'm seeing this errors from pretty much any
> 3D application. Not that all these 3D apps work flawlessly on Wine to begin
> with - haven't seen one yet. But it's been a policy to ignore all messages
> from Wine until user can show the real problem. So far no tests fail - and
> that is the only acceptable "problems" from tests.

Ok, but my point is (and I'm not saying we should necessarily do
this), according to the Wine Developer's Guide an err is something
that we should be concerned about, by definition. If we buy this, and
some current err messages are often harmless, implying no loss of
important functionality, they should be changed to some other channel.

Vincent Povirk

Re: do ERR messages imply bugs?

[David Gerard]

2009/4/12 James McKenzie :

> Bugzilla should request an application name and AppDB entry number.


Demanding an appID number will certainly keep the bug reports down,
though at the expense of bug reporting.

I can't see making bug reports arbitrarily more difficult as a good
way for devs to get an idea of what's broken.


- d.

Re: do ERR messages imply bugs?

[James McKenzie]

Vitaliy Margolen wrote:
> chris ahrendt wrote:
>   
>> 17997 Gecko is installed and reran test... same result... valid bug
>>
>> 17998 is the locking issue... and it occurs not just in the rest but in
>> another application as well..
>> 
>
> What errors? What exactly isn't working for you? You have failed to explain
> that. Until you meaningfully can explain everyone what isn't working for
> you? What exact applications are you having problems with? Where are they
> failed tests you are speaking of, these bugs invalid!
>   
This is why I don't like the current configuration of Bugzilla and how
we pass information along.

Bugzilla should request an application name and AppDB entry number.

We need to make folks 'smart' about why ERR messages appear and what is
different from FIXMEs.

We also need to improve what is in ERR messages as we can provide fix
information as well.

James McKenzie

Re: do ERR messages imply bugs?

[Vitaliy Margolen]

Roderick Colenbrander wrote:
> On Sun, Apr 12, 2009 at 6:53 PM, Vitaliy Margolen
> mailto:wine-de...@kievinfo.com>> wrote:
> 
> Vincent Povirk wrote:
> > Chris Ahrendt filed a few bugs recently for "err" messages encountered
> > during test runs  (17997 and 17998 at least).
> >
> 17997 is a bogus report - Gecko is not intalled. Nothing actually
> failed.
> 17998 is the same. Only I let our resident 3D gurus to respond. I
> don't see
> any problems with tests testing invalid conditions. This most likely
> one of
> those cases.
> 
> If Chris doesn't like err messages, he can shut them off.
> 
> Vitaliy.
> 
> 
> The first ERR line in bug 17998 could indicate a real bug as a program
> is trying to lock a surface which has already been locked.
> 
> err:d3d_surface:IWineGDISurfaceImpl_LockRect (0x132280) Surface already locked
> 
> I'm not sure about the opengl error. It could mean that some display
> driver is offering some render_type flags which I'm not handling yet.
> That can also cause issues.
> 
> err:wgl:get_render_type_from_fbconfig Unknown render_type: 0

This is all well and good, but I'm seeing this errors from pretty much any
3D application. Not that all these 3D apps work flawlessly on Wine to begin
with - haven't seen one yet. But it's been a policy to ignore all messages
from Wine until user can show the real problem. So far no tests fail - and
that is the only acceptable "problems" from tests.

Vitaliy.

Re: do ERR messages imply bugs?

[Vitaliy Margolen]

chris ahrendt wrote:
> 17997 Gecko is installed and reran test... same result... valid bug
> 
> 17998 is the locking issue... and it occurs not just in the rest but in
> another application as well..

What errors? What exactly isn't working for you? You have failed to explain
that. Until you meaningfully can explain everyone what isn't working for
you? What exact applications are you having problems with? Where are they
failed tests you are speaking of, these bugs invalid!

DO NOT REOPEN THEM!

Vitaliy.

Re: do ERR messages imply bugs?

[Vitaliy Margolen]

Vincent Povirk wrote:
> Chris Ahrendt filed a few bugs recently for "err" messages encountered
> during test runs  (17997 and 17998 at least).
> 
17997 is a bogus report - Gecko is not intalled. Nothing actually failed.
17998 is the same. Only I let our resident 3D gurus to respond. I don't see
any problems with tests testing invalid conditions. This most likely one of
those cases.

If Chris doesn't like err messages, he can shut them off.

Vitaliy.

Re: do ERR messages imply bugs?

[Ben Klein]

2009/4/13 Tobias Jakobi :
> Let's repeat this once again: The ERRs he mentions have nothing to do
> with the initial problem described in the report (the MP2 one).

I was going to repeat this, both on this thread and on the MP2 bug
where he posted saying "you don't need MP to reproduce any more"
(which of course is simply hilarious), but I felt like it was
troll-bait more than anything else. It seems to me that Chris thinks
there's a 1:1 mapping between ERR and bug!

Re: do ERR messages imply bugs?

[Tobias Jakobi]

It's either the handling of zero times +infty or the handling of NaN
(how is NaN mapped to a RGBA vector?). OpenGL and D3D do seems to have
different opinions on how this should be done.

On OpenGL there is no word in the standard how it should be done, so
it's essentially undefined behaviour. The nvidia-drivers implement a
non-windows conformant behaviour, while the ati-drivers implement the
handling that is also happening in the Windows drivers. This is both
fine (however not for us).

D3D seems to have a uniform way of handling this, otherwise someone
would have noticed that lighting bugs on native Windows before. That's
not the case, so NaN handling (or the zero * infty thing) is defined
behaviour there (perhaps not covered in the MSDN, but you can't trust
the MSDN anyway..)

I still don't know what Chris wanted to prove in the bugreport.

Let's repeat this once again: The ERRs he mentions have nothing to do
with the initial problem described in the report (the MP2 one). The
visual errors don't trigger any WARNs, ERRs, FIXMEs or whatever. It's
simply that our translation of D3D asm to OpenGL asm or GLSL isn't fully
correct. The resulting shader code is fully valid, however it's not
doing exactly what the original D3D shader code does. And obviously this
doesn't trigger any errors apart from testcases (which we currently
don't have in git master).

Greets,
Tobias

Re: do ERR messages imply bugs?

[chris ahrendt]

Vincent Povirk wrote:

On Sat, Apr 11, 2009 at 11:49 PM, chris ahrendt  wrote:
  

So in the case of the multiple locks and err's the output of the test run is
the same for bug 7284  then
this bug or output would be invalid as well?



The bug description claims it's about lighting effects, not err messages.

Also, the test log (whose relevance to the bug I do not understand)
shows actual failures.
  

the log on that bug also shows the failure I mentioned as well

chris

Re: do ERR messages imply bugs?

[chris ahrendt]

Ben Klein wrote:

2009/4/12 Vincent Povirk :
  

Chris Ahrendt filed a few bugs recently for "err" messages encountered
during test runs  (17997 and 17998 at least).

Vitaliy claims they are invalid.



17997 looks invalid due to missing Wine Gecko. 17998 looks like
uncleanliness in the test to me (trying multiple times to lock a
surface that's already locked). Perhaps this is the point of this
particular test, trying to determine if Wine will crash if the lock is
attempted multiple times? I really can't say, but no programmatic
errors have been reported in either case.

In both it's "Wine gives an err message on stderr", but no loss of
functionality is reported. If they can be fixed without changing the
*intent* of the code (17998 in particular), then it's my opinion that
they are valid as enhancements (which is what the severity is set to).

  

In order to explain clearly why they are invalid, I looked up the
official definition of ERR in the Wine Developer's Guide:

"Messages in this class indicate serious errors in Wine, such as as
conditions that should never happen by design."
(http://www.winehq.org/docs/winedev-guide/debugging)

This goes against my preconceived notion. Bad developer's guide, bad.

To my even greater astonishment, all the ERR messages I've added fit
this description. Bad past self, bad.



I'd say an ERR indicates a potential and/or serious loss of
functionality for a program you're running in Wine. I'm pretty sure
that in some cases, ERRs will be triggered in Wine even when that
particular thing doesn't work in Windows.

  

The consensus (or so I thought) seems to be that ERR messages are
simply for debugging and can safely be ignored as long as nothing is
going wrong in a running program (in this case, as long as the tests
are not failing).



This is certainly true for FIXMEs (which are by definition known bugs,
and in fact can cause loss of functionality in some cases). In the
case of ERRs, if the program runs fine, then all is well :) It's just
that it's much more likely for an ERR to be associated with a broken
program or loss of functionality.

  

"Serious errors" sounds like something that should be worth
investigating, even without visible failures.

How do we resolve this discrepancy?



Probably by disagreeing with everything I've said :P
  


So in the case of the multiple locks and err's the output of the test 
run is the same for bug 7284 
 then this bug or output 
would be invalid as well?


C

Re: do ERR messages imply bugs?

[Ben Klein]

2009/4/12 Vincent Povirk :
> On Sat, Apr 11, 2009 at 11:49 PM, chris ahrendt  wrote:
>> So in the case of the multiple locks and err's the output of the test run is
>> the same for bug 7284  then
>> this bug or output would be invalid as well?
>
> The bug description claims it's about lighting effects, not err messages.

Actually, from what I've read, the bug has been traced to
peculiarities in shader code relating to 0*infinity.

> Also, the test log (whose relevance to the bug I do not understand)
> shows actual failures.

Yes, 7284 is unrelated to 17998, because it's a bug relating to
visible, graphical errors. 7284 is not exclusively about the error
output, whereas 17998 is.

The question that needs to be answered regarding 17998 is: does the
test deliberately attempt to lock the same surface multiple times? If
so, these ERRs are expected and it is either INVALID or WONTFIX. If
not, then maybe the test needs to be cleaned up.

Re: do ERR messages imply bugs?

[Vincent Povirk]

On Sat, Apr 11, 2009 at 11:49 PM, chris ahrendt  wrote:
> So in the case of the multiple locks and err's the output of the test run is
> the same for bug 7284  then
> this bug or output would be invalid as well?

The bug description claims it's about lighting effects, not err messages.

Also, the test log (whose relevance to the bug I do not understand)
shows actual failures.

Re: do ERR messages imply bugs?

[Ben Klein]

2009/4/12 Vincent Povirk :
> Chris Ahrendt filed a few bugs recently for "err" messages encountered
> during test runs  (17997 and 17998 at least).
>
> Vitaliy claims they are invalid.

17997 looks invalid due to missing Wine Gecko. 17998 looks like
uncleanliness in the test to me (trying multiple times to lock a
surface that's already locked). Perhaps this is the point of this
particular test, trying to determine if Wine will crash if the lock is
attempted multiple times? I really can't say, but no programmatic
errors have been reported in either case.

In both it's "Wine gives an err message on stderr", but no loss of
functionality is reported. If they can be fixed without changing the
*intent* of the code (17998 in particular), then it's my opinion that
they are valid as enhancements (which is what the severity is set to).

> In order to explain clearly why they are invalid, I looked up the
> official definition of ERR in the Wine Developer's Guide:
>
> "Messages in this class indicate serious errors in Wine, such as as
> conditions that should never happen by design."
> (http://www.winehq.org/docs/winedev-guide/debugging)
>
> This goes against my preconceived notion. Bad developer's guide, bad.
>
> To my even greater astonishment, all the ERR messages I've added fit
> this description. Bad past self, bad.

I'd say an ERR indicates a potential and/or serious loss of
functionality for a program you're running in Wine. I'm pretty sure
that in some cases, ERRs will be triggered in Wine even when that
particular thing doesn't work in Windows.

> The consensus (or so I thought) seems to be that ERR messages are
> simply for debugging and can safely be ignored as long as nothing is
> going wrong in a running program (in this case, as long as the tests
> are not failing).

This is certainly true for FIXMEs (which are by definition known bugs,
and in fact can cause loss of functionality in some cases). In the
case of ERRs, if the program runs fine, then all is well :) It's just
that it's much more likely for an ERR to be associated with a broken
program or loss of functionality.

> "Serious errors" sounds like something that should be worth
> investigating, even without visible failures.
>
> How do we resolve this discrepancy?

Probably by disagreeing with everything I've said :P