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@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
On Sun, 2005-06-19 at 11:06 -0500, Dustin Navea wrote:
Perhaps, though, instead of asking people who contribute code and 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)..
Stop there -- let's not ask even more out of Alexandre. Unfortunately there are too many such errors to have a snowball chance in hell of documenting them.
Think of them as developer comments.
-
Dimi Paun -
Dustin Navea