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.
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.
uhhh.. believe it or not, submitting bugs in Red Hat products on Red Hat's bug-tracking system, is, in fact the preferred method for submitting bugs in Red Hat products.
Let that soak in for minute.
Now.. if the bug isn't red hat's fault, you should submit it to the author of the software as well. But since it's red hat's responsibility to put out a working product, you should submit the bug there if you're too lazy to submit everywhere.
Sometimes packages don't have bugs reported because people were lazy, or couldn't figure out Bugzilla (not exactly the most user-friendly interface), or they used the wrong package or OS version to report it. But when you put a bug in Bugzilla someone will get an email and it will get handled by someone.
Oh yeah, if you can, FIX the bug and then send in a patch.
1) just because you submit a bug in open source code doesn't mean it will EVER get fixed. Open source developers often have other things they must do to earn a living.
2) If you want good response and professional treatment, pay for a support contract with a reputable company.
Otherwise you get answers like the ones on Slashdot - completely useless, most often insulting, generally caustic, and totally pompous!
Where it == "effectively submit bug reports to the right database". I mean, there is almost as many practises as there is open source projects. Well, sourceforge defines one quite common interface. But still, maybe there really would be the need to create some common "protocol", "method" or "mechanism" or "interface" which would make it easier to deliver the bug report to the correct place. If it made sense and was "enforced" with some well known instance, maybe it could be done. A kind of router mechanism that finds the path for the bug report even if you send it to the wrong place initially. So, basicly we would need another open source project to develop this system, and the resulting mapper would then have to be integral part of the development tools of most projects. Uh oh, at this point I started wondering whether this is understadble or not, but what the heck, let's hit "Submit".
Sometimes, maintainers will even fix the bugs themselves, and work to have the patch merged with upstream source.
Or rather the pro-OSS argument. The alternitive, closed source software, means that you HAVE ALLREADY PAID and have little or no recourse if the vendor does not wish to fix the bug no matter how much you pay.
Personally I prefer to have most bugs fixed by the kindness of strangers and have the guarenteed option of buying a fix on the open market if that dosen't work out.
It's not the size of your .sig that matters, it's how you use it.
This topic is particularly apt, as I was just now thinking I should try to see If I can find a version of Opera that works better.
I have a major pet peeve about "one way" communication. I always wonder if I'm wasting my time to carefully document a crash. Maybe the but has already been fixed after all... I'm not going to go the extra mile unless I can get some idea that I'm breaking new ground, and not just kicking a dead horse.
I have submitted some bug reports for Opera.. And I'd even be willing to trouble shoot, debug, and even submit diffs, if I could only get some feedback from the project team regarding the dispostion of the problems I submitted.
I Like Opera. I'd like it to not lock up once or twice a day like it does.
Hear, hear. I normally have to read those atrocities of the written word at least three times to make any sense of them. ZING!
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.
If you aren't willing to do some bug tracking yourself, then why should you expect someone else to do it in their "free" time? If you have a problem with a Free Software package you have one of three choices.
If gaim didn't compile on your RedHat box chances are very good that someone else has also had the same problem. A quick search of Gaim's mailing lists should turn up relevant posts. If no one else has had your particular problem then asking on the list is appropriate.
My experience with bug reports is that most mailing lists are quite friendly even when a particular "issue" is very well known. They might tell you to RTFM, but they probably will at least point you at the right part of TFM. It has also been my experience that Free Software hackers appreciate your help debugging their software, but only if you actually do the background work. If you expect Free Software hackers to be interested in your bug report you need to be prepared to either give them money or do enough homework so that you are a help instead of an inconvenience.
A good place to start (without having to get a CS degree) would be reading How to Report Bugs Effectively, and of course How To Ask Questions The Smart Way.
Programming can be fun again. Film at 11.
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.
If you mod me down, I *will* introduce you to my sister!
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.
int func(int a);
func((b += 3, b));
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.
Opinions on the Twiddler2 hand-held keyboard?
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?
:-)
They all standardise on Bugzilla, and use Bugzilla's import and export (or move) features to move bugs between instances
Other bug trackers (e.g. Scarab) also support import of Bugzilla's XML format for bugs.
Gerv
Look, these "major projects" are getting hammered by clueless dolts who haven't done any research, where a "bug" is something like "The script stops working when I call a function I never defined".
They get jaded. And why not? They are HUMAN.
A while ago, I hit a nasty (for me) bug in PHP 4.x. Basically, if you tried to include a file that wasn't there, the script would halt with an error.
And being that include() is a function, I felt that it should behave like any other, and return a failure code and continue, leaving it up to you to trap the error.
For me this was important, but I had to rally for a while with the developers, and get past the RTFM stuff, and argue my case before they accepted my logic and made the fix.
But they do care! Just understand their situation, and work from there.
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
/bug/ |z0 a nu fea2ure j00 iz +4|k|n l|k3 u 4i|\|+ g0+z n0 c3n+z!!
Searching for previous instances of bugs on Bugzilla is so haphazard/useless that the only way to be sure that your bug gets reported is to post it and pray that you are not duplicating.
The interface of Bugzilla is *awful*, the search is dreadful and then, when you actually do the work of submitting a bug carefully, its; "SUX 2BU bgz|4h l00zr, your
THEN you get lots of emails from other l00z4az who are submitting the same bug.
The fact that people are submitting the same bug over and over is a clear indication that bugzilla DOESNT WORK VERY WELL, and that it needs to be overhauled from the ground up.
ATH0 Bitcoin: 1DnwFLXczVZV8kLJbMYoheUrpqHesjxrSi
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!
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
I don't think there are many people using Linux because it came pre-installed on their computer, although that might change with these $200 Linux PCs starting to appear on the market. Although I think salesmen are discouraging the sales of these (they must work on commission).
I recently went to a large retail store to buy a computer for my grandmother and saw what looked like 2 identical computers. One was $200 and one was $300. I use Mandrake and LFS at home and W2K and Sun at work so it didn't click that the $200 computer was running KDE. I made a remark to the salesman and he said, "you don't want that one, it's linux."
With just a little training he could have said, "That's a linux system. All you're going to do is word processing and email? This will be perfect for you. It's reliable, low cost, and software upgrades are free. This row of printers will work great with that system." It almost makes me want to hang out there for a couple of hours each Saturday as a volunteer "Linux Marketing Specialist." Come on now, if they have it in inventory they should at least know something about it.
This space intentionally left blank.
Compare your experiences with the following:
We bought a couple of ICP-Vortex RAID controllers (expensive puppies). When we got the controllers, we found a problem: trying to get into their "BIOS" (ICPCON, by hitting ^G) would make the system lockup. Secondly, it required a floppy to upgrade the firmware; we wanted to see if there's a way around it.
We called Intel (who owns Vortex). The operator says: "fork over $25 before I transfer you to a live person; else go to this URL".
Not wanting to part with the $25 so soon, we went to the URL. Vortex wasn't even mentioned anywhere. Finally, a colleague sent email to icp-support@intel.com. Waited for a few days, and he got a canned reply ("No").
But what about the ICPCON question?, he asked. Waited for 1 whole week, and got another canned email, with the wrong answer.
He has sent email to Intel again. The saga continues.
The moral of the story: just because its "free", please don't expect better support than you get for software that you paid money for! At least be realistic.
...if the users fill it full of crap because they can't waste their precious time doing a little research...
I appreciate your point, but there's the other side of the coin where a bug description is in l33t hacker speak or colloquial language which makes searching for its existence very difficult. eg. using the word "horked" instead of "broken".
Re shutting down your online bug tracker and limiting reports to the mailing list: does that mean that everyone who wants to report a bug must first subscribe to the mailing list? Pretty soon everyone is on a mailing list for every piece of software they ever used!! Argh, my aching mailbox.
A little overstated for effect [g] but you can see how that would be a problem, especially if someone is strictly a user of your program, and is neither interested nor involved in its development, but was just trying to be helpful by reporting a bug. "Sign up for a mailing list just to report this stupid bug? Forget it!" And maybe you lose some critical insights as to how *average users* are experiencing your program.
Good point tho, about making sure bug reporters include contact info.
~REZ~ #43301. Who'd fake being me anyway?