do ERR messages imply bugs?

[Ben Klein]

2009/4/12 Vincent Povirk <madewokherd+8cd9 at gmail.com>:
> 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