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

Re:Many liasons simply don't care, however

[Jason Earl]

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.

Re:Ummm... duh?

[IdleTime]

Not that easy man...

Joe User BUYS a package with RedHat 8.0 form a computer store. They expect that if they have a problem with a program, RedHat is the correct address for the bug-report. They don't care who wrote the program, to them it is RedHat

So as you can see, the problem is a little bit more than just blac and white. Most of the posters here think geek and tell you to even submit a patch or a testcase. Joe User doesn't know what a patch or a testcase is.

In my opinion, the distribution should have a report/search client (webpage?) where Joe User can submit a report like "Uhmm.. Prog X doesn't start when I click on the icon." And don't laugh, this is hte type of problems Joe USer faces and they have no clue how to figure out what is the problem.

Remember! Linux is starting to hit a usergroup that has very little knwoledge about OS, programming, debugging etc. This is where the support program from the Vendor should take care of their issue.

Re:Many liasons simply don't care, however

[lkaos]

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.

Re:Many liasons simply don't care, however

[orthogonal]

However, the authors usually will look into the bugs if you mail them directly as "URGENT," though it may take a few tries.

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.

Please do *not* submit your bugs only to disros!

[hardaker]

I'm the lead developer of the net-snmp package and let me give you my 2 cents on the subject from a first hand view:

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!