Ben Klein wrote:
2009/4/12 Vincent Povirk <madewokherd+8...@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
So in the case of the multiple locks and err's the output of the test
run is the same for bug 7284
<http://bugs.winehq.org/show_bug.cgi?id=7284> then this bug or output
would be invalid as well?
C
