Submitting Bug Reports To Open Source Projects? 288
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.
Ahh...but you see (Score:2, Funny)
So they don't *want* to make it easy for you.
Maintainers. (Score:5, Informative)
Re:Maintainers. (Score:2)
Re:Maintainers. (Score:3, Funny)
Re:Maintainers. (Score:3, Insightful)
Re:Many liasons simply don't care, however (Score:5, Insightful)
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:Many liasons simply don't care, however (Score:5, Informative)
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.
Re:Many liasons simply don't care, however (Score:2, Informative)
Re:Many liasons simply don't care, however (Score:2)
It is not the tool, it is the lack of human interaction.
Re:Many liasons simply don't care, however (Score:3, Insightful)
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.
Submission Guesswork (Score:4, Interesting)
I agree that it is difficult and confusing often to report bugs. It seems like many reports are either way too detailed or over simplistic.
I had a bug that was causing me problems printing to a network printer. When I went to submit a bug on the project I scoured the lists. Finding nothing that matched, I submitted my bug, describing my system, program versions, the fact that the exact same setup had worked under a previous version, and what the symptoms were. When I get the info back on my submission it appears that "my" bug had already been described and fixed. The problem was that the original submitter had a programmer's level of knowledge about the problem, and described it in those terms (blah-blah doesn't change blah-blah-blah in blah.cfg), without mentioning the symptoms the enduser would experience.
I don't know what the solution is; the Buzilla documentation is pretty good about explaining how to submit a good bug report, it's just that many people don't follow the guidelines, then the maintainers just let original description through without editing for clarity.
Oh gosh, this has reminded me of my many horrible bug hunts on Bugzilla. What a great topic for Hallowe'en--I'll be awake all night!
Re:What utility software? (Score:3, Interesting)
they are a user. you are a programmer. it's your code. They have no obligation to spend any more time on it than they feel like(conversely, you don't have to spend time on them either).
You must remember, they're doing you a favor by reporting a problem with your code. keep that in mind.
don't alienate them by telling them they have to fill out a 4 page questionaire and search a huge database for related bugs. For some people that's just more time than they want to spend.
I understand what your saying, but most bug reporters are doing it out of the goodness of their hearts. If they are treated like shit because they are new to bug reports and do something wrong, you can bet that'll be the last they fill out.
then ask yourself this- can you see your grandmother filling out a bug report? imagine it from her shoes if you want real insight.
Re:Many liasons simply don't care, however (Score:3, Insightful)
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:Many liasons simply don't care, however (Score:4, Informative)
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.
Re:Many liasons simply don't care, however (Score:5, Insightful)
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 (Score:2)
Yes, but that is the misconception; that free software is the same as a piece of commerical software.
It's like being in a development environment and working on a tool with a bunch of other developers. It reaches a point where it's reasonably stable and one may start using it beyond just testin. One would do so though entirely at his own discretion. He would never think of complaining that it doesn't work.
Re:Many liasons simply don't care, however (Score:5, Insightful)
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.
Re:Many liasons simply don't care, however (Score:3, Informative)
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.
Slashdot bug report (Score:5, Funny)
Re:Slashdot bug report (Score:5, Funny)
Steps to reproduce:
1) Submit story to slashdot
2) Set topic wrong
3) Watch as editors post it anyway
Actual results: story is posted in the wrong section
Expected results: story is posted twice, then an editor should apologise
---------- Comment by Hemos, 10:05pm
Dupe of bug #133340985732
---------- Comment by CmdrTaco, 10:08pm
Marking WONTFIX
---------- Comment by CowboyNeal, 10:09pm
VERIFIED
man pages (Score:5, Interesting)
-BlueLines
Re:man pages (Score:4, Informative)
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.
Ummm... duh? (Score:5, Informative)
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.
Re:Ummm... duh? (Score:2)
Re:Ummm... duh? (Score:3, Insightful)
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.
Re:Ummm... duh? (Score:5, Insightful)
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:Ummm... duh? (Score:2)
If he expects this, he probably did not read the lisence argreement. All RedHat (and most other Linux vendor) promise him is limited installation technical support, which means: we'll help you with basic installation of RedHat, and we are not responsible for any bugs, applications not running, or anything else.
Re:Ummm... duh? (Score:4, Insightful)
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.
Re:Ummm... duh? (Score:2)
Oh, but that's easy! Simply become an expert in whatever language is used, and you can easily file bug-reports :-)
But seriously, sending to both is probably easier and just as effective if you have made sure it's not reported several times before.
Re:Ummm... duh? (Score:3, Insightful)
A good place to start (without having to get a CS degree) would be reading How to Report Bugs Effectively [greenend.org.uk], and of course How To Ask Questions The Smart Way [tuxedo.org].
A good start (Score:3, Informative)
Re:A good start (Score:3, Insightful)
Hear, hear. I normally have to read those atrocities of the written word at least three times to make any sense of them. ZING!
uh what? (Score:4, Insightful)
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.
Re:uh what? (Score:2, Interesting)
Thank You!
I thought I was the only person who hated Bugzilla's UI. I can use it, but I think it is incredibly messy and hard to use. When I want to do quick searches, I have to pretend to be entering a new bug, since the normal search form has way too many useless details on it.
Re:uh what? (Score:2)
The query page was recently reordered to put the more commonly-used things at the top, and make it more understandable. Have you used the new version (it's been the default on bugzilla.mozilla.org [mozilla.org] for a few months.
When I want to do quick searches, I have to pretend to be entering a new bug, since the normal search form has way too many useless details on it.
QuickSearch is also available on the front page
Gerv
Re:uh what? (Score:2)
Gerv
One of the many problems in the field (Score:5, Informative)
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.
bugzilla (Score:2, Informative)
Some things may not have bugs because the problems are with the upstream code, not the Red-Hat-specific package.
Others just need more people to file reports.
Bugzillas (Score:3, Informative)
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.
Report bugs to the distro; it's easy and works (Score:4, Informative)
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.
Email (Score:3, Informative)
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.
Find the central point for the software in questio (Score:2)
database and getting familiar with it. Do a quick Google search with
the name of the software (OpenOffice, Mozilla, Gimp, whatever), and in
most cases you'll find the primary website for that project. (This
may be on sourceforge, as you cite, and some programs are hosted at
redhat, but many projects have their own site.) Small projects may
have an email address where you should send bug reports. Larger
projects usually have some kind of bug database. Bugzilla is the
one I like best, but there are others (Jitterbug for example). Like
I said, if it's an app you use constantly, you may be interested in
more than just reporting your bug -- searching to see if it's already
been reported, perhaps even already been triaged or even fixed, or
how soon that is likely to happen, and so on. Some projects also
include feature requests in the same database, so you can track the
upcoming features that interest you. If the site is using one of the
better issue tracking packages, you can even add your name to a list
to be notified when the bug is changed or fixed.
If it's an app you use only infrequently, you may not want to go
to quite so much trouble as all that.
They Don't/Shouldn't (Score:5, Interesting)
I get the lucky job of also providing tech support for the software I write. I get a lot of users calling up and saying "I got an error printing a report", which leaves me having to ask, "which of the 50 reports and what does the error say". At that point the customer needs to walk back to his office and turn on his computer since he thought I could magically solve the problem without any information and remotely control the little gnomes in his machine and instruct them to magically fix it.
How many open source developers, most of which develop the software for free, want to deal with people that are not technically savvy enough to read the documentation for the software to figure out where to submit bugs to?
Of course, I'm not an open source developer so maybe they like dealing with dumb users and I'm just talking out my ass. It's happened before
Re:They Don't/Shouldn't (Score:3, Funny)
Re:They Don't/Shouldn't (Score:3, Funny)
Of course they should (Score:3, Interesting)
That, in and of itself, disqualifies your evidence as relevant.
Tech Support for non-OSS* is written for people who cannot / are not allowed to / are never expected to understand what's going on.
Bug reports, (especially in OSS), on the other hand, are intended for an audience that can be (and often is) assumed to know what's going on, and how the system works. Any descent bug reporting system tells the reporter to document everything, to reproduce it, and only gives them the ability to submit a bug after they've gone through a UI at least as complex as that of the help documentation for the program.
Or in other words... OSS folks don't deal with dumb users, they deal with dumb admins**--who are often flamed away so quickly that only the halfway competent admins remain.
_________________________
*: OSS: Open Source Software ("OSS Software" would be redundant.)
**: Everyone who uses OSS is or works with or is an admin, even if it's just someone on their own machine in their own basement.
Re:Of course they should (Score:2)
The original post was in reference to GAIM. Are you telling me you've completely missed all the furvor about Desktop Linux? You don't really think end users are having admins install it do you? Red Hat 8.0 is being touted as their first good step towards Desktop Linux.
Like it or not, end users coming, and some of them are incompetant, AND want to submit bug reports.
Please don't flame them and send them back to Windows.
Re:Of course they should (Score:2)
I was just booted in RH8, and it was a PITA. Sure, if my entire PC was RH it might work, but it isn't.
That said, Linux is by-nature a thing for "admins", even if it's a lonely amatuer just installing the OS for the first time. They're not a user, they're an admin--and admins should know what they're doing.
Like it or not, end users coming, and some of them are incompetant, AND want to submit bug reports.
No end user is without an admin in Linuxland. By deciding to go to Linux, they're either a wannabe hacker or a business choosing the cheaper deal.
Please don't flame them and send them back to Windows.
Absolutely not. I plan on flaming red hat for making such an irritating system. (How can the system be HARDER to use than XP? I mean, really!)
Re:They Don't/Shouldn't (Score:2)
Re:They Don't/Shouldn't (Score:2)
Re:They Don't/Shouldn't (Score:2)
Most users, if given explicit instructions, can ferret out enough information for me to determine whether it's a big, a misfeature, an issue, or a non-problem.
Of course, what often [0] happens with these people is that they never reply with further information and I close the bug after a decent time (a year or two)
Daniel
[0] I'd estimate 50-75% of the time.
Re:They Don't/Shouldn't (Score:4, Interesting)
Specifically I was dealing with MoodLogic (not OSS but useful) support. I unchecked the box that says "change all by artist" and it went ahead and changed all by that artist anyway. When I wrote in, support intentionally misunderstood and told me not to check the box as, obviously I must have done because there was no bug.
I wrote back in excrutiating detail how I understood the difference between a checked radio button and an unchecked radio button, explained precisely which songs I was attempting to fix and what the fix should have been. I then explained precisely the order in which I hit the buttons with which mouse button, and what state the checkbox was in at the time.
The reply again assumed I was an idiot and told me to uncheck the box because there was no bug.
Frustrating as hell to know what you're doing and deal with people who don't believe that you do.
Fill the Bug with redhat (Score:3, Informative)
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.
Call him up, be nice... (Score:4, Interesting)
It's not like the commercial software world, where there may be hundreds of employees and a series of support levels. The developers are all there is, and they may not check all the available bug watch sites because they would rather concentrate on making a better piece of spare time software. Contacting them directly will not only alert them to the error, but probably flatter them as well.
I got an email a while back from somebody who had been using a freeware encoding translation app I wrote a while back as an essential piece of a corporate mailing package. It was very cool to see how they were using it and how different it was from the original intent. Eventually, I arranged for the fix I suggested and he wrote to go up on the sparsely updated freeware site I had set up at my university.
Of course, he was willing to fix the bug in this ancient software himself with a little input. If he had come at me with a lengthy email accusing me of writing buggy software or threatening legal action or demanding a fix on code that really was dead to me, etc, I probably would have ignored him.
By the way, you hit the nail on the head of the anti-OSS argument here. There is really nobody accountable for these bugs, legally or otherwise. You're relying on the kindness of strangers, and if they aren't willing/don't have the time to fix it themselves, you're going to have to pay to have somebody else do it.
Re:Call him up, be nice... (Score:3, Insightful)
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.
Re:Call him up, be nice... (Score:3, Interesting)
Relying on the kindness of strangers does not seem like the best idea. BUT quite a lot of OSS developers consider products to be 'their babys' and take some pride in them.
Some companys support is good and you get good value for money. Others are usesless. It would be nice to see a comparison of the life cycle of an open/closed source bug.
the support paradox (Score:2, Informative)
The authors of OSS "products" frequently do have an attachment to their child. But, unlike our real offspring, there ARE things that take precedence over providing timely support of those "products". Additionally, there is far less of an explicit commitment implied as these "products" are donations, and thus it is unreasonable to expect much ongoing commitment.
My experience over a twenty four+ year career in software... OSS "products" that everyone uses are well supported so long as "everyone" is having the same problem you are. If you are using something most others are not, and the bug is something only you encounter, then the only way you will get it fixed is to open it up and fix it yourself. This is the sole benefit of OSS as I see it... if it is important enough to you, you can always fix the code yourself, or pay someone sufficiently to fix it. With non-OSS, you do have to depend on the producer of the product, and if they truly do not want to make the change/fix you need, it is never going to happen unless maybe you buy the company.
When the software profession is in depression, as it currently is, there are lots of highly skilled software engineers with time on their hands and a need to keep their skills sharp. Thus, there are lots of qualified people with the time available to fix OSS bugs.
What will happen when the industry turns around and we are back to the days of scarce engineers? All of the skilled engineers will be running as fast as they can to keep up in their paid work. That leaves the only people with time free to work on OSS are those no one wants to hire. Are these the folks we want fixing the bugs in our software?
How about some additional angles on this line of thought...
If OSS products are not sold, but support is, isn't the incentive on the side of shipping with as many bugs as possible and then charging for the support everyone needs to get the bugs they hit resolved? And how does this differ from commercial software, where one pays up front and then there is a commitment by the producer to provide bug fixes into the future? In the latter case, there is no money in producing bug fixes, so the incentive is to produce the product with the most unfixed bugs that users will tolerate on initial release and then ignore as many requests to fix bugs as possible without loosing too many of those customers?
send your bugs to.. (Score:5, Funny)
Use the unix move command (Score:5, Funny)
You can submit bugs to almost any project with the unix move command (mv)
- Make a text file with your favorite editor.
- Be sure to name the text file with a good summary
- Edit the text file to include the version of the software you are using, a long description of the bug, and any other relevant information
- Submit the report with the command: mv <file>
/dev/null
See, its all in one place and its easy!Re:Use the unix move command (Score:5, Funny)
- Wrap the paper with the bug report around a brick.
- Drive up to your neighbors house and throw the brick through the window.
Re:Use the unix move command (Score:5, Funny)
There's a bug in step 4 of your process. I just submitted a bug report with more details.
Re:Use the unix move command (Score:2)
Oh I love doing things as root
You never know if it's vendor specific (Score:2, Insightful)
The situation is easier if you have a fix. Then you can look at the source packages whether it's an upstream bug, or a vendor bug. Logically, send the fix to both in the former case, and to vendor in the latter case.
Post all bug reports to Slashdot (Score:5, Funny)
Well, maybe you just can't do it efficiently today (Score:4, Insightful)
pet peeve, don't call us, we'll call you (Score:4, Insightful)
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.
Re:pet peeve, don't call us, we'll call you (Score:2)
Re:pet peeve, don't call us, we'll call you (Score:2)
Not only do they not have any public bug database, but they don't even have ANYWHERE to report bugs to (at least on the sites i've seen) - not even an email address. I eventually sent a report to the "web team", surprise surprise, no response.
Bugzilla rocks. It's one of the best things about the project.
duh, opera's not libre/OSS (Score:2)
Re:pet peeve, don't call us, we'll call you (Score:2, Informative)
If Opera is crashing, try increasing your swap or adding new swap space. I found that this decreased crashes from several per day to once per week or so. (There seem to be some pretty large memory usage in current versions at times.)
Java is (supposedly) fixed for the last time in 6.1. Try it.
Have a vendor? Report to them! (Score:5, Informative)
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.
Is the bug in the latest release by the author? (Score:2)
Forget Gentoo (Score:2, Interesting)
That was the first bug I reported to them, and it will be the last. I don't recommend Gentoo to anyone anymore.
Don't piss on people when they are trying to help, Gentoo developers
Re:Forget Gentoo (Score:2, Interesting)
Why doesen't the Open Source Community... (Score:3, Interesting)
mailing lists, forums, then BTS (Score:3, Informative)
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'.
Ho I do ... (Score:5, Informative)
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 [kde.org] very conveniently.
Gaim bugs (Score:3, Informative)
Identify yourself! (Score:5, Informative)
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:Identify yourself! (Score:3, Insightful)
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.
go to redhat (Score:3, Interesting)
I feel that if they put it on their cdrom then they should hvae tested it some. They will also know or should know the best way to contact the maintainer. They also may be appling their own patches to the code. They do this in the linux kernel and I am sure that they do it elsewhere, so it may actually one of their patches that caused the problem.
I had a problem on my system recently where I upgraded from RH 7.2 to RH 7.3 and my passwd file was locked. I removed the .pwd.lock file the ptmp file and any other file that I could think of. I even boot the system into init 1 and init 2 and tried but it was still locked. Then I installed RH on a second drive and booted the second drive and the second system recognized the /mnt/etc/passwd file as still being locked. I thus had to reinstall RH 7.3 wiping out my system. Thank goodness I had mount points from /opt and /home that I saved data on and did not loose anything. I also save important /etc files as well. So it was about 3 to 4 hours to rebuild the system tops from a new install.
So who is responsible for useradd? For vi / vim? For /etc/passwd? I have no idea, but in redhats database there is now a bug about this as I feel that it is their software at some point.
Re:go to redhat (Score:3, Informative)
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
Re:go to redhat (Score:2)
Observations of a forelorn bug submitter (Score:5, Interesting)
I have given up on submitting bugs through bugzilla (not just complaints, I give what it must be like for developers below):
1. You have to log in. Sometimes the registration process requires a lot of information or hand shaking emails. It's an impediment.
2. You have to search for your bug. How are you going to find it? It's not a google-like search engine. You have to count on people submitting the bug with a description that you will understand.
3. You have to spend a lot of time describing your bug. What if others don't understand it? What if the developer does not understand it?
From a developer's perspective:
1. They are only getting the perspective of the ardent few. Will that help them expand the user base and make the project a success? Possibly not, since the majority of people who have problems might just give up.
2. Will they understand what people have described?
3. Will they be able to reproduce the bug? Do they have the configuration to do so?
Just my two cents,
Bud
Distro != Open Source Package in most cases (Score:4, Interesting)
The degree of divergence between the two determines whether it is appropriate to send the bug report to either or both. In most (but not all) cases the distro will be lagging behind the OSS package bugfixes so it's very likely that it's already been fixed.
The real solution, of course, is to ditch all distros and build everything from sources yourself [linuxfromscratch.org].
Responsiveness of Mozilla developers (Score:3, Interesting)
I've only submitted one bug in a distribution package (to Debian), and I saw a reply as well -- 3 months later. Although I still use Debian, responsiveness is probably not high on the list of reasons I do. Then again, most Debian maintainers are volunteers but a substantial chunk of Mozilla developers are paid, so that probably explains it.
What? (Score:2)
Dude, the source is right there...
The right place to submit bugs (Score:3, Insightful)
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 [tigris.org]) also support import of Bugzilla's XML format for bugs.
Gerv
HAMMERED! (Score:3, Insightful)
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
Please do *not* submit your bugs only to disros! (Score:5, Insightful)
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 [freshmeat.net] 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!
Free -vs- pay (Score:3, Insightful)
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.
Re:Well (Score:2, Funny)
Re:Why worry? (Score:2)
Re:Why worry? (Score:2)
NOOO!!! (Score:2)
This is EXTREMELY bad advice! Unless you know for a fact that the bug was not introduced by a vendor patch, there's an excellent chance that the only result will be an annoyed developer who has wasted a bunch of time on a bug that has nothing to do with him, who has just classified you as a clueless twit and who has now added you to his killfile/spamfilter.
ALWAYS start with the vendor, and go to the developer only if a) the vendor advises you to do so, or b) you get no useful response from the vendor (and in the latter case, make sure you mention this fact to the developer, so that he's aware that the bug may not exist in his code).
The only exception is if you've audited the code, and you KNOW the problem is in the developer's code, not the vendor's patches, and even in that case, you should notify the vendor TOO, so that they are aware of the problem, and can take appropriate steps.
Re:Goto the developer (Score:2)
Re:Christ, is this a troll or what? (Score:2)
The last time I did try to report a flaw with a Microsoft product I was told that was just the way it worked and I would have to live with it. Even then that was after a 33 minute on hold time phone call.
So while you have a question about which route to use to report OSS bugs, at least there are several methods to chose from.
Re:Mantis (Score:3, Informative)
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 [kde.org] for an example of an excellent customisation.
Gerv
Re:DUH (Score:2)
6 wait for a few days, get response saying "cannot reproduce, what version are you running, and where did you get it?"
7. send email naming your vendor
8. wait a few more days, get a response saying "vendor must have broken something, talk to them, not us"
9. feel sad at how much time you wasted.
10. contact vendor like you should have done in the first place.
Re:redhat loves fucking up packages (Score:2)
Thanks guys.