On Fri, 11 Apr 2003, Ed Wilts wrote: >Note, however, that all you currently see in that bug report is reports >from users - there is no confirmation from Red Hat that this is a bug >and not user error or something else. > >Just because it's been reported by users as a bug doesn't make it one >(so says a guy who spent part of his career in tech support). Boy that really hits the nail on the head in my books. I get a great many bug reports filed against XFree86, and quite a number of them are simply not bugs at all. Close something that is obviously not a bug as NOTABUG, and quite often you get an angry inflamatory user response in return. Other bugs get reported in which the problem is as clear as mud, either because the person can not adequately describe it and provide enough technical information that an assessment can be made on the alleged problem, or because the problem itself is just too vague and/or unreproduceable. 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. Any sane rational person realizes first and foremost that there is no 100% confirmation that this person's problem *IS* an XFree86 bug. It could be an X bug, a kernel bug, a network card driver bug that hangs during a DMA transfer locking up the PCI bus and causing the graphics adaptor to corrupt the display due to inability for the device to communicate any longer. It could be a broken video card, an incompatibility between the card and the motherboard chipset in the current configuration, bad power supply, bad RAM, buggy motherboard BIOS, APM related bug that only occurs while X is running for some reason or another, or any of a number of other explanations. Nonetheless, beacuse X happens to be running at the time, when the user comes to the computer and sees that moving the mouse does not cause the mouse pointer to move on the screen, and perhaps sees video corruption - bang - they automatically assume there is an XFree86 bug, and that it is due to a flaw in Red Hat development or QA process and that we should now drop everything we're doing and spend 3 weeks investigating this problem, even purchasing $500-$10000 worth of hardware we don't have to look into the issue - perhaps to find out 3 weeks and 120 man hours later that the motherboard BIOS is buggy. Doh. Sucks to be Red Hat and just wasted 120 man hours of effort. These types of bug reports are unfortunately all too common, and increasing more and more. The reality of the situation, at least for XFree86 problem reports, is that if a problem is transient, or unreproduceable at will by the person having the problem, it will be difficult if not impossible for us to even investigate it. If the person can reproduce it, and we can not reproduce it, it also is very difficult if not impossible to investigate. If problem reports do not contain enough information and detail, regardless of how "bad" a problem hits a person or group of people, we can't really pull a magic rabbit out of our red hats and cast a spell to fix some alleged problem. I say "alleged" with all seriousness too, because often these problems end up being user misconfiguration, or user misunderstanding of how something works. Some times it is just because configuring a particular thing is so complicated that a user just cant figure it out, and they think they have done it right and it isn't working so therefore it is a bug in the software. This gets more complicated when it isn't clear on *OUR* side how something is supposed to work either. It's not always easy to determine if what a user is doing is right or wrong in the first place due to the enormity of the configuration options available and complexity of the whole system. I'd hate to spend 3 days troubleshooting a user's problem with some configuration area I'm unfamiliar with to find out they're not configuring it properly in the first place and that there is no bug. That kind of work is technical support, not bug fixing. Unfortunately, a lot of user problems and bug reports lay in a grey area between "bug report" and "technical support request for help". Those type of problems quite often are NOTABUG or are NOIDEA or NEEDINFO - at least until there is enough information to make a judgement either way, and then wether or not there is enough info to debug/troubleshoot the given problem and perhaps fix it. Nonetheless, the majority of bug reporters with obscure problems that don't have much information to provide in order for a decent assessment to be made are a constant source of joy in a developer's day. ;o) The moral of the story I guess, is that there are only so many hours in a day, and more reports of alleged bugs than developer hours. Common sense dictates developers prioritize investigating and/or fixing problems that are the most reproduceable and affect the most amount of people with higher priority, and leave the bugs that are unreproduceable or very complex to investigate and/or affect the least amount of people potentially with low priority. Gotta draw a line in the sand somewhere. ;o) Ok, my weekly long email is over. As y'were. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat
