On Thu, Jul 15, 2010 at 8:45 AM, Dan Kegel dank@kegel.com wrote:
- the FIXME_ONCE guy; I think you and I are giving him the same advice;
http://www.winehq.org/pipermail/wine-devel/2010-July/085069.html so that seems fine.
Aha. This is the thread that probably bothered you: http://www.winehq.org/pipermail/wine-devel/2010-June/084309.html (and here's where you explained your position: http://www.winehq.org/pipermail/wine-devel/2010-July/085070.html )
The advice I gave him was
I'd suggest starting by looking at http://bugs.winehq.org/show_bug.cgi?id=15435 "Wine logs too verbose, quieter fixme's needed" and sending in a patch to make one of the overly-verbose fixme's a bit quieter. ...
... [ok, can I change FIXME itself?]
changing FIXME itself might be going a bit too far during the current code freeze. You could try adding a FIXME_ONCE macro, though, and use it to quiet some particular message that really gets in the way of (i.e. slows down) a real application.
I agree that Max's patches and behavior so far haven't been up to snuff, but I'm trying to guide him towards the light in private email (e.g. "The thing to do is to wait until after wine-1.2 is released next week, and then submit your original patch plus a few (say, three) patches to fix existing ad hoc fixme-once instances. Your goal should be to *not* change behavior of wine with this set of patches, but rather make the code more readable and simple.")
(And later, people who are experts at the various DLLs can go look at the FIXME_ONCEs, and deal with the underlying problem properly.)
I agree that any automated way of finding problems, be it compiler warnings, valgrind warnings, or log messages, tends to attract people who try to "fix" them without understanding the underlying issues, with sometimes terrible results, and that one should guard against this and discourage newbies from changing things they don't actually understand. - Dan