Submitting Bug Reports To Open Source Projects? 288
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.
Maintainers. (Score:5, Informative)
Hp? (Score:0, Informative)
Ummm... duh? (Score:5, Informative)
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.
A good start (Score:3, Informative)
One of the many problems in the field (Score:5, Informative)
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.
bugzilla (Score:2, Informative)
Some things may not have bugs because the problems are with the upstream code, not the Red-Hat-specific package.
Others just need more people to file reports.
Bugzillas (Score:3, Informative)
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.
Report bugs to the distro; it's easy and works (Score:4, Informative)
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.
Re:Why worry? (Score:1, Informative)
The correct answer is to find the maintainer and file a bug with him/her/them.
Email (Score:3, Informative)
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.
Re:man pages (Score:4, Informative)
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.
Fill the Bug with redhat (Score:3, Informative)
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.
Have a vendor? Report to them! (Score:5, Informative)
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.
mailing lists, forums, then BTS (Score:3, Informative)
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'.
Ho I do ... (Score:5, Informative)
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 [kde.org] very conveniently.
Gaim bugs (Score:3, Informative)
Identify yourself! (Score:5, Informative)
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.
Mantis (Score:1, Informative)
Bugzilla looks ugly and is no software for endusers. Even worse there is no free project that hosts Bugzilla for small projects without an own server. Sourgeforge Bugreports are not state-of-the-art and too slow.
the support paradox (Score:2, Informative)
The authors of OSS "products" frequently do have an attachment to their child. But, unlike our real offspring, there ARE things that take precedence over providing timely support of those "products". Additionally, there is far less of an explicit commitment implied as these "products" are donations, and thus it is unreasonable to expect much ongoing commitment.
My experience over a twenty four+ year career in software... OSS "products" that everyone uses are well supported so long as "everyone" is having the same problem you are. If you are using something most others are not, and the bug is something only you encounter, then the only way you will get it fixed is to open it up and fix it yourself. This is the sole benefit of OSS as I see it... if it is important enough to you, you can always fix the code yourself, or pay someone sufficiently to fix it. With non-OSS, you do have to depend on the producer of the product, and if they truly do not want to make the change/fix you need, it is never going to happen unless maybe you buy the company.
When the software profession is in depression, as it currently is, there are lots of highly skilled software engineers with time on their hands and a need to keep their skills sharp. Thus, there are lots of qualified people with the time available to fix OSS bugs.
What will happen when the industry turns around and we are back to the days of scarce engineers? All of the skilled engineers will be running as fast as they can to keep up in their paid work. That leaves the only people with time free to work on OSS are those no one wants to hire. Are these the folks we want fixing the bugs in our software?
How about some additional angles on this line of thought...
If OSS products are not sold, but support is, isn't the incentive on the side of shipping with as many bugs as possible and then charging for the support everyone needs to get the bugs they hit resolved? And how does this differ from commercial software, where one pays up front and then there is a commitment by the producer to provide bug fixes into the future? In the latter case, there is no money in producing bug fixes, so the incentive is to produce the product with the most unfixed bugs that users will tolerate on initial release and then ignore as many requests to fix bugs as possible without loosing too many of those customers?
Re:Many liasons simply don't care, however (Score:5, Informative)
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.
Re:pet peeve, don't call us, we'll call you (Score:2, Informative)
If Opera is crashing, try increasing your swap or adding new swap space. I found that this decreased crashes from several per day to once per week or so. (There seem to be some pretty large memory usage in current versions at times.)
Java is (supposedly) fixed for the last time in 6.1. Try it.
Re:Many liasons simply don't care, however (Score:4, Informative)
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.
Re:Mantis (Score:3, Informative)
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 [kde.org] for an example of an excellent customisation.
Gerv
Re:go to redhat (Score:3, Informative)
clue about what file it tried to open when it said the passwd file was locked.
if you can ammend your bug with that pathname, it may help to fix the bug that you have run across
you really didn't need to reinstall just to fix that
Re:Many liasons simply don't care, however (Score:3, Informative)
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.
Re:Many liasons simply don't care, however (Score:2, Informative)
Re:Many liasons simply don't care, however (Score:2, Informative)
For example, my own project has a very extensive user manual, which some people say is the best they ever saw for a open source project. It's over 150 pages long and clearly explains everything you can do with our software. From installing, upgrading, configuration and how to actually use the application. It even has a section on how to use the user interface. It's not written for programmers, but for the everyday user, who don't want to know what makes our software tick, but how to make it tick. Still we get a lot of questions about the simplest things, which are explained in detail. The user just has to open the manual, look in the index for the right chapter and start reading.
The same thing applies to filing bug reports. There is an explaination on the submit form which clearly lists what information we need to solve the problem. Still we get bug reports just saying 'X not work, fix please'. I'm just a programmer, not a mind reader!
Also I started rewriting the titles of the bugreport to make it more clear for the users and nowadays I add the status of the bug in the title, so users can see what is fixed and what is not even before reading the report. Would you submit a report for a bug which is marked as 'FIXED:' and listed on the first page a user sees when he wants to submit a bug? Again people don't read.
Of course we do get useful and understandable reports about real problems. If this is the case I try my best to solve the problem as quickly as possible. But unfortunately there are still too many users who are either too lazy to read or think it's easier to ask than try to find the answer yourself. It not only makes me cranky, but steals time away I could otherwise spend on fixing other peoples problems or spend on creating that new feature everybody is waiting for.
(Yes, I am the AC you replied to, didn't have my login information on me at the time)