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?
would be to check the README many times there is instructions there on where to stubmit bug reports.
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
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.
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.
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.
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.
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.
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
use strace -e trace=file to run the program, and it will give a
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
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.