On Friday 15 September 2006 00:16, ken wrote:
The obvious point is that the misidentification isn't the cause of the misconfiguration. What the exact cause is couldn't be determined, because the reporter *wouldn't say how it was misconfigured*. All he said was "it doesn't work, I changed something and now it works"
The bug reporter gives more than that. He does say that the error is caused by sax2, yes? He does specify his video card and the one erroneously reported by sax2. Plus, the reporter did offer to run a diagnostic on his machine, as long as it didn't write any changes to his system.
The important thing was to say what was changed. This was not reported. But if a diagnostic can be run, then the existing (working) xorg.conf should be copied to somewhere safe, and then sax2 should be run to "screw it up". Then both files should be sent in. That would be quick, easy and informative, and it would give the developers something to work with.
And he did provide a correction to the pci.ids table.
This is not important for anything, it isn't used except for users' convenience.
Not enough? You should warn your customers that they'll be held to very high standards if they ever want to (not even need to) report a bug.
High standards? If someone says "It failed, I changed something and now it works, please fix it", I don't think it qualifies as high standards to ask what was changed.
What if a bug report comes in and the user doesn't know what's causing the problem? He just knows that, upon install, the screen gets messed up. Do you just close the report and forget about the bug (what this developer did)? If that's the case, then it *is* silly to report a bug.
If the problem is currently occurring, then I would ask the user to send in his malfunctioning configuration together with log files and system hardware information. This is information NEEDED (not optional, not "a nice thing to have", but literally needed) to work on debugging a problem If the problem is not currently occurring, and it can't be reproduced to give the above information, then there is nothing anyone can do to solve it. It simply is not possible to debug a bug that isn't there anymore. Sorry, but this is just the way things work Like I said in another mail, there are just two ways of doing this: either the problem is produced locally, in which case the developer can get all the info he needs for himself; or the user with the problem sends in all the information. There is no inbetween, there is no way anyone (or even any hundred) can look through the source code looking for a bug that no one knows where it is or exactly what it does