On Sat, 12 Apr 2003, M A Young wrote: >> An example of this, is the type of bug report where a user >> reports "X locks up my computer when I am away". Digging deeper >> I learn that it happens for the person about once a month and >> just on one machine. The user is very upset and rude in their >> bug report as to how Red Hat could have possibly released such >> an unstable product. > >Do you want bugs like this reported? I have one which pretty much exactly >fits this description which I haven't got around to putting into bugzilla >yet. I have more details, but probably not enough to work out what the >problem is at the moment. Not really. Bug reports that are vague, are very transient, or are not easily reproduceable tend to just fill space in the bugzilla SQL database rather than be tremendously useful. It is much preferred that users experiencing such problems try to pinpoint the problem down to something more concrete before reporting it, or discuss the problem on XFree86 mailing lists to try to obtain help on how to try and narrow it down. Just try to use as good judgement as you can, and if you think the problem you've got really is a bug, and that the problem is likely going to be easy for someone else to reproduce, and you can give specific details on how to do so and also include your X server config file and log file, kernel messages file and any other useful tidbits that might remotely be of use to a developer investigating the problem, then file a bug report if you like. Also, if a given bug seems likely to be a general XFree86 bug that is not Red Hat Linux specific, you may want to report it to XFree86.org directly in their bugzilla: http://bugs.xfree86.org In general, reporting a bug upstream when you've got good reason to believe is likely generic to XFree86, and not specific to Red Hat Linux maximizes the number of X developers who will look at the bug report and possibly fix it. If you also file a tracker bug report in our bugzilla, I can track the upstream bug report as time goes on too, and add any fixes that come out of it into our packages, or backport them from CVS. Another benefit of upstream bug reporting, is that fixes get integrated upstream much much faster, and other Linux distributions and open source OS's benefit from the fixes sooner too. Also, the number of users reading the reports is cross OS and cross vendor, so there are more eyes, and more feedback from more sources. I've experimented a bit with refering certain types of bug reports upstream to test the fix-rate, and it has proven to be very good for some kinds of bug reports. One example is almost any bug report related to the keyboard not working properly, be it certain keys or key combinations not working, modifier problems, currency symbols missing, missing | < > keys, and most other keyboard related problems tend to sit around forever in our bugzilla, but upstream they tend to get fixed anywhere from the day they're reported to a few days or a week later. Ivan Pascal fixes xkb related bugs like a wild animal, and so I recommend anyone experiencing such keyboard related bugs file them in XFree86.org's bugzilla, and once it's fixed, open up a bug in our bugzilla to request the fix be added to our packaging, or just CC me on the upstream report as <mharris@xxxxxxxxxxxxxxxx>. That gets such bugs fixed very much faster both upstream, as well as in our releases. Another bug report type likely to be fixed upstream faster, are DRI related bugs. Right now, incoming DRI related bug reports on XFree86.org get reassigned to the dri-devel mailing list, which automatically hits every DRI developers mailbox. That is a much faster mechanism to get a DRI bug fixed than stuffing it in our bugzilla so that one person (me) might look at it months from now in my spare time perhaps if there are no higher priority tasks on my queue. Of course one can always file bug reports in both places and cross reference the 2 with URLs also in order to have a given issue tracked in both places and maximize eyes seeing the issue even more. Just remember to narrow a given problem down as far as you can on your own and get as much detailed information as possible when filing a bug report. Include as full a description of the problem as you can, including how reproduceable it is (please don't say "didn't try" for reproduceability - try it, especially if it is an oddball). Include step by step detailed instructions on how to reproduce, and include hardware details, X log, X config file, kernel log, lspci output, and any possible thing that could help a developer. More information the better - if it isn't needed it wont be used. If it is needed though and it isn't there, from a developer's view trying to drag information out of people is like trying to find Saddam at the bottom of a pile of rubble. <grin> Anyhow, I hope this provides some helpful insight into when, how, where, and why to report X bugs. Take care, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat
