Documenting debug messages (was: wine/dlls/x11drv x11drv_main.c x11drv.h palette.c)

[Dustin Navea]

You are right, it is completely different, but I was just stating that I 
think it might be something to consider, just so that we non-developers 
have some clue about what different errors mean..  I, for one, would 
like to know what the error message in my original reply means.  And 
having some sort of documentation on that exact error message would save 
everyone some time from having to close reports that are already known, 
as well as the advantage of not having to answer questions about that. 
Basically answer the question once for me, and then people can just 
search (using their browsers' find function) for that exact error on 
whatever page it gets put on, whether wiki or my own personal site.

Perhaps, though, instead of asking people who contribute code and add an 
err to update the documentation, we should setup a script that will 
track cvs commit emails (and the attached patch) and just ask alexandre 
to explain what would cause the fixme/err/warn/etc that is in that patch 
(in the commit email of course)..

I could probably rent a shell to run it, and have the script either 
update the doc itself, or have it email the explanation to me, and then 
update the pages myself whenever I have a chance...

The first thing though would be to get the current debug messages 
documented somewhere, then worry about updating it.

Of course, if I do go ahead and document it, I would leave the removed 
messages in there with a note saying "this has been removed as of 
(date), please update to the latest release, or latest CVS if there 
hasn't been a release since this was committed"..

Of course if I dont have any support, then there's no sense in doing it, 
so I would only do this with the blessing of the other developers.

Dustin

Brian Vincent wrote:
> On 6/15/05, Dustin Navea <speeddymon at gmail.com> wrote:
> 
>>I'd have to agree with you guys on this one.  One thing I can think of
>>that I would like to take on (given enough time to do it all) is create
>>a wiki page that I can use to document all of the fixme's, warn's and
>>err's that occur in the source, and then ask anyone that is contributing
>>code to update it when they add/remove one of those.  For example, it
>>might be helpful to a user to know that "err:midi:OSS_MidiInit ioctl on
>>midi info for device 0 failed" is more of a fixme than an error, and
>>exactly what that "gibberish" means, so that they dont go reporting it
>>(making a dupe report), etc..
> 
> 
> Well, this is completely different than the config option (registry
> value) argument..
> 
> I don't think it's worth spending any time on.  It doesn't provide
> that much useful information and it will quickly rot - people won't
> keep it updated.
> 
> But that's just my $.02.
> 
> -Brian
>