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.

Comments

Maintainers.

[crimsun]

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

Ummm... duh?

[mikeage]

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.

One of the many problems in the field

[haplo21112]

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.

Have a vendor? Report to them!

[The Man]

The rule I always follow is to report bugs in software shipped by a vendor (ie RedHat, Debian, etc.) to that specific vendor rather than to the upstream maintainer directly. This is because vendors often apply their own patches to the canonical sources; these patches sometimes alter behaviour or locations in a way that would make the report meaningless to the authors. Of course, sometimes these patches also add or remove bugs themselves and are often the cause of the unexpected behaviour.

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.

Ho I do ...

[uhlmann]

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.

Identify yourself!

[Dominic_Mazzoni]

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.

Re:Many liasons simply don't care, however

[einhverfr]

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.