Chris Ahrendt filed a few bugs recently for "err" messages encountered during test runs (17997 and 17998 at least).
Vitaliy claims they are invalid.
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.
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).
"Serious errors" sounds like something that should be worth investigating, even without visible failures.
How do we resolve this discrepancy?
Vincent Povirk
2009/4/12 Vincent Povirk madewokherd+8cd9@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
Ben Klein wrote:
2009/4/12 Vincent Povirk madewokherd+8cd9@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
On Sat, Apr 11, 2009 at 11:49 PM, chris ahrendt celticht32@aol.com wrote:
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?
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.
Vincent Povirk wrote:
On Sat, Apr 11, 2009 at 11:49 PM, chris ahrendt celticht32@aol.com wrote:
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?
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
2009/4/12 Vincent Povirk madewokherd+8cd9@gmail.com:
On Sat, Apr 11, 2009 at 11:49 PM, chris ahrendt celticht32@aol.com wrote:
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?
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.
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
2009/4/13 Tobias Jakobi liquid.acid@gmx.net:
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!
An Excellent point was mad in one of the bugs I reported :
Comment #25 from Austin English austinenglish@gmail.com
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
2009/4/13 chris ahrendt celticht32@aol.com:
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 celticht32@aol.com:
An Excellent point was mad in one of the bugs I reported :
Comment #25 from Austin English austinenglish@gmail.com
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.
Ben Klein wrote:
2009/4/13 chris ahrendt celticht32@aol.com:
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 celticht32@aol.com:
An Excellent point was mad in one of the bugs I reported :
Comment #25 from Austin English austinenglish@gmail.com
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
2009/4/13 chris ahrendt celticht32@aol.com:
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.
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.
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..
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.
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
2009/4/12 James McKenzie jjmckenzie51@earthlink.net:
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.
David Gerard wrote:
2009/4/12 James McKenzie jjmckenzie51@earthlink.net:
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
2009/4/12 James McKenzie jjmckenzie51@earthlink.net:
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.
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
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
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
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
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.
-
Ben Klein -
chris ahrendt -
David Gerard -
James McKenzie -
Tobias Jakobi -
Vincent Povirk -
Vitaliy Margolen