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. ;-)
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?
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.
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.
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.
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.
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.
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 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.