Slashdot Mirror
Submitting Bug Reports To Open Source Projects?
aldheorte writes "After installing Red Hat Linux 8.0, I discovered some minor bugs. Some of these are with software actively maintained by Red Hat (e.g. redhat-config-date), but some are not (e.g. gaim). Although it is possible to enter bugs for any package at Red Hat Bugzilla, some of these packages have zero bugs, which probably indicates this is not a preferred method of receiving bugs for that project. In fact, I've found this to be the case for for several project. I find no listed bugs for Red Hat's Bugzilla and a whole database of bugs at another site, such as SourceForge. There are many distributions and channels for open source projects to reach the end user, so how do users, especially non-technical ones, effectively submit bug reports to the right database? How do open source projects make it easier for users to submit bug reports and consolidate the bugs in a single database?" Update: 11/01 11pm EDT by C :Don't know why this was sitting under the "HP" topic, so I've changed it to something more appropriate. Sorry if this has resulted in any confusion.
With most of the large Linux distributions, maintainers (sometimes multiple) act as liaisons between users and "upstream" authors. Case in point: Debian GNU/Linux, where each package is maintained by at least one maintainer. You, the user, submit a bug report to BTS, where the maintainer collects further information and passes it along upstream. (That was the simplified version.) Ultimately extra patches or bugfixes, etc. may be rolled into upstream's source. Bugs are closed in BTS. Behold the power of source. ;-)
This story has the HP logo for an icon, while it's not about HP at all.
I suffer from attention surplus disorder.
read the man pages. usually there's contact info for the maintainer of the actual program. also, always file the bug with your vendor as well, so they have a chance to upgrade their shipping versions.
-BlueLines
--BlueLines "The cost of living hasn't affected it's popularity." -anonymous
Well, the bug should be filed with the person with whom the responsibility lies. Examples:
Redhat configuration utility: Redhat
Gaim: Gaim
Gaim packaging by Redhat: Redhat
Gaim packaging by gaim: gaim
(I don't know (or care) who makes the RPMs)
The only problem is a conflict.. say... gaim doesn't compile with, say, GCC. Then, the task would be to determine if gaim is non-compliant, or if gcc is non-compliant (or both). In that case, if I don't want (or don't know enough) to track it down, I'd file both.
-- Is "Sig" copyrighted by www.sig.com?
would be to check the README many times there is instructions there on where to stubmit bug reports.
Although it is possible to enter bugs for any package at Red Hat Bugzilla, some of these packages have zero bugs, which probably indicates this is not a preferred method of receiving bugs for that project.
uhhh.. believe it or not, submitting bugs in Red Hat products on Red Hat's bug-tracking system, is, in fact the preferred method for submitting bugs in Red Hat products.
Let that soak in for minute.
Now.. if the bug isn't red hat's fault, you should submit it to the author of the software as well. But since it's red hat's responsibility to put out a working product, you should submit the bug there if you're too lazy to submit everywhere.
Sometimes packages don't have bugs reported because people were lazy, or couldn't figure out Bugzilla (not exactly the most user-friendly interface), or they used the wrong package or OS version to report it. But when you put a bug in Bugzilla someone will get an email and it will get handled by someone.
Oh yeah, if you can, FIX the bug and then send in a patch.
The answer however is simple, most of the gui apps include info on their orgins. Following that information will lead you to the right place. The commandline apps typically have information on their origins in the man pages for the app, so thats usually the best way to go in thats case.
The alternative is of course look up the package on freshmeat (http://www.freshmeat.org). That will definatively lead you to the developer of record for the software.
All else fails google it of course.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Speaking only on bugzilla places like Red Hat and Mozilla, any bug you file will generate an email to someone, so that bug report should at least get looked at.
Of course, with limited resources, they may have to decide how big of a priority your bug is, but you should probably at least try to go through the estabished bug-reporting channels before deciding that they don't work.
Just because a package has zero bugs reported doesn't mean that nobody looks at those bug reports - it means that no users care enough to file anything on them. Tons of bugs in the "unconfirmed" state would be a better indication that nobody looks at them.
In my experience (which is based on using RedHat and Debian), distributions let users report bugs for any package at the site because it is easier for users, and it lets them respond to problems that are due to distribution-specific changes.
The package maintainers will look at the bug and figure out if it is specific to the distro. If it is, they respond directly. If it is not, they forward the report (or fix) upstream. Reporting the bug to your distributor lets them know that someone has seen the bug and it has been a problem for at least one of their users.
This should not stop you from submitting bugs directly upstream -- usually the package maintainer will follow the bug reports for the package, and if you mention the relevant distribution in the bug, they notice it -- but there is usually no great benefit to doing so.
At least for Debian, open bug reports also let the distribution track which packages need particular help and whether the package has been abandoned in a bad state. I assume RedHat uses a similar mechanism.
Personaly what I do is I submit a bug report (debian's reportbug) and depending on what the bug is I will also email the person who wrote the program.
By emailing the author I feel that you get a faster response. By submitting the bug report you make more people aware of it.
That's just my thoughts though.
Blink
so how do users, especially non-technical ones, effectively submit bug reports
;)
I get the lucky job of also providing tech support for the software I write. I get a lot of users calling up and saying "I got an error printing a report", which leaves me having to ask, "which of the 50 reports and what does the error say". At that point the customer needs to walk back to his office and turn on his computer since he thought I could magically solve the problem without any information and remotely control the little gnomes in his machine and instruct them to magically fix it.
How many open source developers, most of which develop the software for free, want to deal with people that are not technically savvy enough to read the documentation for the software to figure out where to submit bugs to?
Of course, I'm not an open source developer so maybe they like dealing with dumb users and I'm just talking out my ass. It's happened before
Fill the Bug with RedHat because they might have local changes in their version of the packages.
The Best example of this is gcc (at least for version 2.96 which was never released by the FSF). People fill bugs under the gcc bug tracker but the bugs were already fixed in the newest released version.
A lot of these open source projects are maintained by one or two people. Many of them are in the phone book or have an email address lying around. You might as well just contact them directly.
It's not like the commercial software world, where there may be hundreds of employees and a series of support levels. The developers are all there is, and they may not check all the available bug watch sites because they would rather concentrate on making a better piece of spare time software. Contacting them directly will not only alert them to the error, but probably flatter them as well.
I got an email a while back from somebody who had been using a freeware encoding translation app I wrote a while back as an essential piece of a corporate mailing package. It was very cool to see how they were using it and how different it was from the original intent. Eventually, I arranged for the fix I suggested and he wrote to go up on the sparsely updated freeware site I had set up at my university.
Of course, he was willing to fix the bug in this ancient software himself with a little input. If he had come at me with a lengthy email accusing me of writing buggy software or threatening legal action or demanding a fix on code that really was dead to me, etc, I probably would have ignored him.
By the way, you hit the nail on the head of the anti-OSS argument here. There is really nobody accountable for these bugs, legally or otherwise. You're relying on the kindness of strangers, and if they aren't willing/don't have the time to fix it themselves, you're going to have to pay to have somebody else do it.
Hey freaks: now you're ju
Well you should really be sending your bug reports to HP. That way they'll be fixed....
You can submit bugs to almost any project with the unix move command (mv)
- Make a text file with your favorite editor.
- Be sure to name the text file with a good summary
- Edit the text file to include the version of the software you are using, a long description of the bug, and any other relevant information
- Submit the report with the command: mv <file>
/dev/null
See, its all in one place and its easy!Might as well since we already hear about every minor software release anyway.
Where it == "effectively submit bug reports to the right database". I mean, there is almost as many practises as there is open source projects. Well, sourceforge defines one quite common interface. But still, maybe there really would be the need to create some common "protocol", "method" or "mechanism" or "interface" which would make it easier to deliver the bug report to the correct place. If it made sense and was "enforced" with some well known instance, maybe it could be done. A kind of router mechanism that finds the path for the bug report even if you send it to the wrong place initially. So, basicly we would need another open source project to develop this system, and the resulting mapper would then have to be integral part of the development tools of most projects. Uh oh, at this point I started wondering whether this is understadble or not, but what the heck, let's hit "Submit".
This topic is particularly apt, as I was just now thinking I should try to see If I can find a version of Opera that works better.
I have a major pet peeve about "one way" communication. I always wonder if I'm wasting my time to carefully document a crash. Maybe the but has already been fixed after all... I'm not going to go the extra mile unless I can get some idea that I'm breaking new ground, and not just kicking a dead horse.
I have submitted some bug reports for Opera.. And I'd even be willing to trouble shoot, debug, and even submit diffs, if I could only get some feedback from the project team regarding the dispostion of the problems I submitted.
I Like Opera. I'd like it to not lock up once or twice a day like it does.
If a bug is major or affects security I will also mention it to the authors, especially if I'm feeling non-lazy and have reproduced the bug with the standard sources. And, of course, if I am using some software I built myself from the original sources, I will report the bug directly to the maintainer in all cases rather than my distribution vendor.
As a software author, it's often annoying when a distributor applies patches to software that add, remove, or change feature sets and may introduce additional bugs. Some maintainers will definitely not be willing to help you at all with packages built by others for this reason. Linux is a fine example - try asking sometime about the Red Hat kernel on LKML. Be prepared for flames and/or silence - after Red Hat applies their 500 patches nobody on that list will be willing even to look at your problem.
develop a central bug reporting site. A few dedicated people or moderators could take on the responsibility of passing all their bugs to the developers. But more importantly developers would have a one stop place to get bugs, as well as distributors. You could probably use bugzilla to do this. Even set it up to forward bug reports to the bugzilla site of each project automatically. Wouldn't this make it easier for users of software(especially non technical ones) to have a place to report bugs?
I tried for 5 years to come up with a clever sig...only to realize that I am not clever.
Most OSS programs provide some sort of detail regarding who maintains the program -- usually in an AUTHORS file or a README file. And, usually, these files explain where the project's website is. Going there, you'll, again, usually, find a lot of resources for you, the user: mailing lists, forums, IRC channels, and more. (I personally prefer mailing lists.) Use those resources to dig around a little -- see if the bug has been addressed already and a fix is in CVS or a new version. If, and only if, you find that the "bug" you've found has not been addressed and is specific to this application, should you go to the bug tracking system for that project -- and on the BTS maintained by your distribution or package maintainer (this way they will release a new version). If the bug has been addressed, and you're seeing it because you have an outdated version from your distribution's packaging system, then file a bug on the packaging system's BTS asking them to upgrade to the newer version in order to fix the bug.
If you can't wait for your disto's new package to be released, consider rolling your own with by compiling the program and using such utilities as 'checkinstall'.
How do open source projects make it easier for users to submit bug reports and consolidate the bugs in a single database?"
:-)
I go to "Help" -> "Report Bug". That's it. Wow, the amazing advantages of an standardizing desktop system
In this case it's KDE and it helps me to find bugs.kde.org very conveniently.
Report gaim bugs to the gaim bug tracking at sourceforge. Or, talk to the people in #gaim on OPN. Either way, your bug will get known, and, in the latter case, you might get an answer right away.
Participating in a free software project requires a certain amount of work. Part of the bug submitter's job is making sure that the bug they submit hasn't been submitted 400 times already, or worse yet isn't a FAQ. Bugzilla is a nifty tool, but if the users fill it full of crap because they can't waste their precious time doing a little research then Bugzilla becomes more of a hindrance than a help. After all, if the information in Bugzilla is crap, then it just wastes developer time and makes the project look bad because of the amount of bugs, most of which are bogus.
I imagine that nearly any Free Software hacker would fix your bug if you did your homework beforehand and made sure that it wasn't a duplicate bug. If you provide a simple test case that shows the bug your chances improve dramatically, and if you provide a patch then you might even get your name in the credits.
The fact of the matter is that bad code is better than no code. Otherwise you wouldn't be using a Free Software project that had bugs in it :). The good news is that over time, with enough user testing, all code becomes good code.
Of course, I'm not an open source developer
That, in and of itself, disqualifies your evidence as relevant.
Tech Support for non-OSS* is written for people who cannot / are not allowed to / are never expected to understand what's going on.
Bug reports, (especially in OSS), on the other hand, are intended for an audience that can be (and often is) assumed to know what's going on, and how the system works. Any descent bug reporting system tells the reporter to document everything, to reproduce it, and only gives them the ability to submit a bug after they've gone through a UI at least as complex as that of the help documentation for the program.
Or in other words... OSS folks don't deal with dumb users, they deal with dumb admins**--who are often flamed away so quickly that only the halfway competent admins remain.
_________________________
*: OSS: Open Source Software ("OSS Software" would be redundant.)
**: Everyone who uses OSS is or works with or is an admin, even if it's just someone on their own machine in their own basement.
The most important thing you need to do when submitting a bug report is to give your name and email address. 90% of the time, the author or maintainer will need some extra piece of information from you that you forgot to include.
I'm the lead developer for Audacity, and we get lots of anonymous bugs submitted on our SourceForge bug tracker. Clearly the ones that just say "I tried to use your program but it crashed..." are not at all helpful, but sometimes even people who try to give a very detailed report don't include the one useful piece of information we need to track it down! So please identify yourself. We'll contact you for more information.
To be honest, we're thinking seriously of shutting down the bug tracker for our project on Sourceforge. It's generally far more efficient when people submit the bug to the mailing list, and IF it's valid, one of the developers adds it to our bugs.txt file. Low-tech? Yes, but far more efficient considering we don't have any full-time developers.
I feel that if they put it on their cdrom then they should hvae tested it some. They will also know or should know the best way to contact the maintainer. They also may be appling their own patches to the code. They do this in the linux kernel and I am sure that they do it elsewhere, so it may actually one of their patches that caused the problem.
I had a problem on my system recently where I upgraded from RH 7.2 to RH 7.3 and my passwd file was locked. I removed the .pwd.lock file the ptmp file and any other file that I could think of. I even boot the system into init 1 and init 2 and tried but it was still locked. Then I installed RH on a second drive and booted the second drive and the second system recognized the /mnt/etc/passwd file as still being locked. I thus had to reinstall RH 7.3 wiping out my system. Thank goodness I had mount points from /opt and /home that I saved data on and did not loose anything. I also save important /etc files as well. So it was about 3 to 4 hours to rebuild the system tops from a new install.
So who is responsible for useradd? For vi / vim? For /etc/passwd? I have no idea, but in redhats database there is now a bug about this as I feel that it is their software at some point.
Only 'flamers' flame!
I think the big challenge in open source today is enabling the *easy* interaction between developers and users. The interaction right now is just too costly for both parties. My cut would be that there needs to be further development of automated system slike Mozilla's talkback and that this type of bug reporting should become a *fundamental* aspect of Open Source Development. The current problem with talkback is that it only works for crashes. It would be nice if you had some sort of built-in interaction recording functionality that would allow people to click a button to send a brief playback along with a description of what they did not like.
I have given up on submitting bugs through bugzilla (not just complaints, I give what it must be like for developers below):
1. You have to log in. Sometimes the registration process requires a lot of information or hand shaking emails. It's an impediment.
2. You have to search for your bug. How are you going to find it? It's not a google-like search engine. You have to count on people submitting the bug with a description that you will understand.
3. You have to spend a lot of time describing your bug. What if others don't understand it? What if the developer does not understand it?
From a developer's perspective:
1. They are only getting the perspective of the ardent few. Will that help them expand the user base and make the project a success? Possibly not, since the majority of people who have problems might just give up.
2. Will they understand what people have described?
3. Will they be able to reproduce the bug? Do they have the configuration to do so?
Just my two cents,
Bud
The degree of divergence between the two determines whether it is appropriate to send the bug report to either or both. In most (but not all) cases the distro will be lagging behind the OSS package bugfixes so it's very likely that it's already been fixed.
The real solution, of course, is to ditch all distros and build everything from sources yourself.
I've only submitted one bug in a distribution package (to Debian), and I saw a reply as well -- 3 months later. Although I still use Debian, responsiveness is probably not high on the list of reasons I do. Then again, most Debian maintainers are volunteers but a substantial chunk of Mozilla developers are paid, so that probably explains it.
"You can never have too many elephants on your team."
I am actually thinking that a news-group type system of bug reporting is almost better than a standard bug reporting tool lime Mozilla because other people can then comment etc. on the bug.
The best bug-fix help I have ever seen has been through email lists because the peer support is very good and then if no one has heard of it, a bug report is filed. I have seen this happen on the Samba lists.
LedgerSMB: Open source Accounting/ERP
As a project leader of a large Open Source project on sourceforge, I can tell you some projects do take bugs very seriously. Many submitters of bugs do not. I can't tell you how many users simply do not read the documentation and keep submitting things that are very clearly explained. Many 'bugs' are nothing more than configuration problems, long-time fixed bugs or duplicates.
There are a couple of things to help improve the response to a bug report. Mailing the authors multiple times is not one of them. If the bug is posted in the correct bug tracker and I am not busy I sometimes respond withing 15 minutes. Usually I respond within 24 hours or 48 hours if I am very busy.
If the submitter posts the bug in multiple trackers and also posts the same information on our forums I will simply wait an additional 48 hours before responding. Posting it once is enough to get my attention! Posting it more than once is just plain rude. Some users are so impatient they also mail me with again the same information. Some are even brave enough to send an e-mail every hour or so telling me how urgent their problem is. These are the users I will ignore completely. If I have enough information the bug will be fixed in the next release, but they won't get any feedback in the mean time.
Since I am the one who has to spend time solving the problem I am the only one who can decide if the problem is urgent enough to spend my time on it. If users don't have the decency to go through the proper channels and wait for their turn, my motivation to solve their problem will only go down.
There is the weird notion that with Open Source software, there is such a thing as users and developers and that the users are somehow customers to the developers.
Anyone who uses a piece of Open Source software is a developer of that software. It's the nature of Open Source software. That's the price you pay for using the software. The "user" is just as responsible for product quality as the author.
Keep this in mind when you want to submit a bug report. If you take a consumer mentality and simply say, "Feature x doesn't work like feature y does in program z," you will be ignored; as you deserve to be.
Instead, try to do the most you can do to fix the problem. Isolate the problem, figure out what are all the constraints that it occurs under. If you have worked with code before, take a look at the code and see what's going on. Then once you've reached your limit, if the problem still isn't fixed, transition what you've learned to another developer.
The last thing you should ever do is send a frantic "URGENT" bug-report.
int func(int a);
func((b += 3, b));
Ugh. Bad idea (tm).
The bug may be urgent for you (although in most cases you can find a work-around); it's almost certainly NOT urgent for the author. Don't construe your emergency as my priority.
And definitely don't email more than once: the author will attend to your problem as soon as he can, and no sooner. Probably later if you're pestering him.
That said, I've been lucky enough to have had really great response when I've submitted bugs in open source software. Perhaps I'm just lucky, but let me suggest a few reasons for that luck:
I've always made a point of thanking the author for his work (that is, the software, buggy or not, that I'm running for free and with full source), and telling him how useful it is to me (if it wasn't useful, why'd I care about a bug?).
I acknowledge, before I ask him to do more work for me, that I am asking him to work for free to solve my problem, and I appreciate it and realize what an undertaking it might be.
I try to make it easy for the author to figure out just what I'm talking about, by providing version numbers; descriptions of -- or better -- actual buggy output; my OS and its version(s); program state that appears to trigger the bug; etc.
I take a (cursory, at least) look at the source code, enough to possibly suggest where the problem might lie, attempt some diagnostic if possible, and note that if need be, I'll fix the bug myself (if the source is C, C++, or java). (In other words, I implicitly note that I'm willing to bear the burden I'm asking of him, and also that I'm not completely ignorant about coding.)
So far, this has gotten good response -- as in emails answered within hours, even from authors on other continents, and resolutions in hours or days.
The author of Scintilla/SciTE (an excellent GUI source editor), Neil Hodgson, even went so far as to download updated mouse-drivers to his own box, to better diagnose my problem, and probably spent at minimum four hours on my issue the first night I emailed him. On my part, I looked up some API calls and scanned his code to suggest where the fix might go, and suggested what the fix might be.
With his help, I was able to recompile (his makefile worked right out of the box to my great joy!) my own fix by the next day; he had the fix in with his next regular release.
Albert Faber, author of CDex, was similarly helpful, even though my "bug" hardly was a show-stopper: full song-lyric annotations to playlist text weren't being saved correcly in the local cddb. Herr Faber got back to me in at most a day, acknowledged the bug, and had a fix out in his next release -- and I did little more than make some poor suggestions about what might be causing the error.
I go on at such length, and I apologize for it, to convince you that the best way to get bugs fixed is to step up to the plate and be willing to do your part, while letting the author know that you know how much he has done for you, and how much more he'll be doing if he fixes your bug.
Opinions on the Twiddler2 hand-held keyboard?
IMO, there's not much you can do with an offline bug system client. You can't query the database, update it, run reports, view bugs you haven't pre-cached (which would then be out of date) etc. We get a lot of enhancement requests for Bugzilla, including XML interfaces and command-line clients - but I've never heard a request for an offline client.
Registering in a Bugzilla takes half a minute. People can cope
Bugzilla looks ugly and is no software for endusers.
The UI is fully customisable using templates. See KDE's Bugzilla for an example of an excellent customisation.
Gerv
There are many distributions and channels for open source projects to reach the end user, so how do users, especially non-technical ones, effectively submit bug reports to the right database? How do open source projects make it easier for users to submit bug reports and consolidate the bugs in a single database?
:-)
They all standardise on Bugzilla, and use Bugzilla's import and export (or move) features to move bugs between instances
Other bug trackers (e.g. Scarab) also support import of Bugzilla's XML format for bugs.
Gerv
Look, these "major projects" are getting hammered by clueless dolts who haven't done any research, where a "bug" is something like "The script stops working when I call a function I never defined".
They get jaded. And why not? They are HUMAN.
A while ago, I hit a nasty (for me) bug in PHP 4.x. Basically, if you tried to include a file that wasn't there, the script would halt with an error.
And being that include() is a function, I felt that it should behave like any other, and return a failure code and continue, leaving it up to you to trap the error.
For me this was important, but I had to rally for a while with the developers, and get past the RTFM stuff, and argue my case before they accepted my logic and made the fix.
But they do care! Just understand their situation, and work from there.
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
In the project I maintain I try to fix any bugs I can find immediately, but probably 80% of bug reports are just 'this doesn't work, fix it', or don't include version number, OS, or any pointer to how to replicate the bug. These kinds of bugs don't get fixed quickly.
The worst kind are the 'this works differntly to how I want it to' bugs, which aren't bugs at all (often they're design decisions made because they have to be, other times I'm trying to move things in a particular direction that require the different functionalty). OTOH if the same thing keeps cropping up I'll generally change it because it's indicative of a useability bug.
If you want to get your bug fixed, then remember that the guy on the other end of the email is probably only working on this in his spare time, may well have had a bad day at work, and doesn't need nagging. A polite description of the problem, giving as much information as possible (it's virtually impossible to give too much information in these circumstances) will go a long way. If your query isn't answered immediately be patient, because the maintainer probably has more important things to do at that moment, and will get around to it when he can.
Bugzilla is a nifty tool, but if the users fill it full of crap because they can't waste their precious time doing a little research then Bugzilla becomes more of a hindrance than a help.
/bug/ |z0 a nu fea2ure j00 iz +4|k|n l|k3 u 4i|\|+ g0+z n0 c3n+z!!
Searching for previous instances of bugs on Bugzilla is so haphazard/useless that the only way to be sure that your bug gets reported is to post it and pray that you are not duplicating.
The interface of Bugzilla is *awful*, the search is dreadful and then, when you actually do the work of submitting a bug carefully, its; "SUX 2BU bgz|4h l00zr, your
THEN you get lots of emails from other l00z4az who are submitting the same bug.
The fact that people are submitting the same bug over and over is a clear indication that bugzilla DOESNT WORK VERY WELL, and that it needs to be overhauled from the ground up.
ATH0 Bitcoin: 1DnwFLXczVZV8kLJbMYoheUrpqHesjxrSi
Distributions do a great job redistributing stuff, but don't do a great job working with the package authors themselves. The net-snmp package is an extremely hard one to maintain, for we support a really large number of operating systems for code which is very operating system sensitive (the architecture ifdefs in some portions of the code will drive you mad. Trust me.) net-snmp is redistrubuted through a number of distributions, and let me tell you that almost no bug reports get to us that are entered into distribution bug tracking databases. It's a nightmare, and because we can't continously search other bug databases for problems, we frequently are left out.
To make matters worse, the distributions often fix things. RedHat and other RPM packages simply roll their own patches into their redistribution and don't send it to us. FreeBSD has a ports tree that contains patches for projects that the projects themselves may have never seen.
I'll never forget the first time I opend the source rpm of the net-snmp package from redhat. There were 3 patches in it that I had never seen for bugs I didn't even know about. Why hadn't I heard of them? because the RedHat package maintainers didn't notify us that they had fixed something.
Finally, what's even worse is that all of the RedHat source RPMs are GPLed. Our package uses a BSD license and thus we can't pull the patches out of the RPMs and apply them to our source without getting explicit permission to re-license it.
The proper thing to do would be to probably search freshmeat for the project page and look at the documentation. Maybe submit it to both the package maintainer and to distribution maintainer if you really have the time (ha!).
My personal plea to the distribution maintainers: help the package authors out! Please!
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
because they can't waste their precious time doing a little research
they are a user. you are a programmer. it's your code. They have no obligation to spend any more time on it than they feel like(conversely, you don't have to spend time on them either).
You must remember, they're doing you a favor by reporting a problem with your code. keep that in mind.
don't alienate them by telling them they have to fill out a 4 page questionaire and search a huge database for related bugs. For some people that's just more time than they want to spend.
I understand what your saying, but most bug reporters are doing it out of the goodness of their hearts. If they are treated like shit because they are new to bug reports and do something wrong, you can bet that'll be the last they fill out.
then ask yourself this- can you see your grandmother filling out a bug report? imagine it from her shoes if you want real insight.
Looking for Book Reviews? Check out Literary Escapism.
Compare your experiences with the following:
We bought a couple of ICP-Vortex RAID controllers (expensive puppies). When we got the controllers, we found a problem: trying to get into their "BIOS" (ICPCON, by hitting ^G) would make the system lockup. Secondly, it required a floppy to upgrade the firmware; we wanted to see if there's a way around it.
We called Intel (who owns Vortex). The operator says: "fork over $25 before I transfer you to a live person; else go to this URL".
Not wanting to part with the $25 so soon, we went to the URL. Vortex wasn't even mentioned anywhere. Finally, a colleague sent email to icp-support@intel.com. Waited for a few days, and he got a canned reply ("No").
But what about the ICPCON question?, he asked. Waited for 1 whole week, and got another canned email, with the wrong answer.
He has sent email to Intel again. The saga continues.
The moral of the story: just because its "free", please don't expect better support than you get for software that you paid money for! At least be realistic.
I agree that it is difficult and confusing often to report bugs. It seems like many reports are either way too detailed or over simplistic.
I had a bug that was causing me problems printing to a network printer. When I went to submit a bug on the project I scoured the lists. Finding nothing that matched, I submitted my bug, describing my system, program versions, the fact that the exact same setup had worked under a previous version, and what the symptoms were. When I get the info back on my submission it appears that "my" bug had already been described and fixed. The problem was that the original submitter had a programmer's level of knowledge about the problem, and described it in those terms (blah-blah doesn't change blah-blah-blah in blah.cfg), without mentioning the symptoms the enduser would experience.
I don't know what the solution is; the Buzilla documentation is pretty good about explaining how to submit a good bug report, it's just that many people don't follow the guidelines, then the maintainers just let original description through without editing for clarity.
Oh gosh, this has reminded me of my many horrible bug hunts on Bugzilla. What a great topic for Hallowe'en--I'll be awake all night!
...if the users fill it full of crap because they can't waste their precious time doing a little research...
I appreciate your point, but there's the other side of the coin where a bug description is in l33t hacker speak or colloquial language which makes searching for its existence very difficult. eg. using the word "horked" instead of "broken".