Posted
by
Cliffon Thursday October 31, 2002 @04:50PM
from the getting-your-roaches-lined-up-in-a-row dept.

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.

Ahhh....but you see grasshopper...if you can't report a bug, then the project is perfect, and the developer can say "See...my code is l33t!!!" when he applies for the high-paying job in the cubicle farm.

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

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.

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.

Have you ever actually used Bugzilla? The whole point is that it supports user commenting and tracking after the initial report is filed. It's esentially an easy way of creating mailing lists for each bug.

Bugzilla is a great tool. But the best bug support has been through email lists. This is because known issues are either ignored or pointed out relatively quickly. And if a bug report does not contain sufficuent information but looks interesting, more information will immediately be requested.

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.

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/bug/ |z0 a nu fea2ure j00 iz +4|k|n l|k3 u 4i|\|+ g0+z n0 c3n+z!!

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.

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!

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.

...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".

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.

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.

I agree with you to a certain extent, however a user of a piece of software is just that, a user.

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.

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.

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.

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.

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.

Yeah, but without doing serious bug tracking yourself, it is sometimes hard to figure out which of any number of piece the bug belongs to (distro? package manager? C libraries? actual application? some dependency of the application?... etc.)

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.

You can try a different package (perhaps a commercial product).

You can pay someone else to fix your problem (RedHat support for example).

You can do some troubleshooting yourself.

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.

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.

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.

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.

Joe User needs to find a knowledgeable friend or his friendly local LUG

I couldn't agree with you more. Most people won't try out Linux without knowing someone who knows what they are doing. My parents are still learning the finer points of email, but they use Mandrake 9.0 just fine because I take care of all the difficult stuff for them. People who don't know someone are usually the adventurous type who pick up a boxed set and are therefore willing to do a little bit of learning to submit a good bug report. The only other group I can think of are admins who are forced by policy to use linux at work. They should know what they are doing anyway. All three types of people can benefit from a LUG.

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.

Simple. They should stop hiding behind insisting to be non-technical users. If they care, all the information needed is out there for free, otherwise chances are their bug reports won't be too helpful anyway.

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.

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.

couldn't figure out Bugzilla (not exactly the most user-friendly interface)

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.

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.

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.

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.

Speaking only on bugzilla places like Red Hat [redhat.com] and Mozilla [mozilla.org], 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.

If it's an app you use a lot, it's worth finding their primary bugdatabase and getting familiar with it. Do a quick Google search withthe name of the software (OpenOffice, Mozilla, Gimp, whatever), and inmost cases you'll find the primary website for that project. (This may be on sourceforge, as you cite, and some programs are hosted atredhat, but many projects have their own site.) Small projects mayhave an email address where you should send bug reports. Largerprojects usually have some kind of bug database. Bugzilla is theone I like best, but there are others (Jitterbug for example). LikeI said, if it's an app you use constantly, you may be interested inmore than just reporting your bug -- searching to see if it's alreadybeen reported, perhaps even already been triaged or even fixed, orhow soon that is likely to happen, and so on. Some projects alsoinclude feature requests in the same database, so you can track theupcoming features that interest you. If the site is using one of thebetter issue tracking packages, you can even add your name to a listto be notified when the bug is changed or fixed.

If it's an app you use only infrequently, you may not want to goto quite so much trouble as all that.

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

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.

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.

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.

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.

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!)

On the other hand, it helps to have some bug reports. The developers can't test every possible use of their software, and they usually only test it on one computer. As an open source developer, I want to make it easy for people to report bugs so I can fix them.

Usually when I get a bug report like that I send an email back politely asking the user for more information. (only 'usually' because if the bugreport was along the line of "your software sucks and you stink and I am going to burn your house down and eat your children" I might have to settle for "civil" instead of "polite")

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)

My most frustrating experience with support was submitting a bug report and having the developers tell me that the bug simply didn't exist.

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

A lot of these open source projects are maintained by one or two people. Many of them are in the phone book or have an email address lying around. You might as well just contact them directly.

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.

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.

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.

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.

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.

Support truly IS a critical aspect of OSS, as no software is ever totally free of bugs. With the traditional commercial model, independent of when money is exchanged, there is an explicit commitment by the producer of a software product to provide support. While execution on that commitment is quite variable, this IS accountability as there is a company name and reputation attached to a software product.

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?

Thus you should always report it to the vendor. Eg. RedHat created many bugs on its own (sometimes I think they added at least as many bugs as they fixed) and the package may be considerably customized or it may not have an upstream maintainer at all. If the upstream version seems to be maintained well, send it upstream too.

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.

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 [sourceforge.net] 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".

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.

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.

Ex-squeeze me, but what does Opera have to do with a discussion about bug reports for free/libre/OSS projects? If Opera were OSS, then you'd have some options. If the original developers ignore you, you could beg or pay someone else to fix the problem, or take some programming classes and learn to fix it yourself. As it is, you're the one that chose the proprietary solution, so you're stuck, and I hope you weren't expecting any sympathy around here!:)

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

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.

Sometimes packages are only available of older versions of a program (for example, gaim). Is the bug still in the latest version of the program from the author? Or has 's maintainer just not made a new version of the package? A lot of times this is the case, so emailing the author wastes their time. Your best bet is usually to go with the package maintainer. If the bug hasn't been fixed yet, they'll either work on the bug or tell the author about it...

I filed a bug for Gentoo and the person maintaining the package was a total jerk about it. He copped a complete "I am so l33t" attitude. Rude, unhelpful and elitist is no way to run your project, people.

That was the first bug I reported to them, and it will be the last. I don't recommend Gentoo to anyone anymore.

develop a central bug reporting site. A few dedicated people or moderators could take on the responsibility of passing all their bugs to the developers. But more importantly developers would have a one stop place to get bugs, as well as distributors. You could probably use bugzilla to do this. Even set it up to forward bug reports to the bugzilla site of each project automatically. Wouldn't this make it easier for users of software(especially non technical ones) to have a place to report bugs?

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'.

Report gaim bugs to the gaim bug tracking [sourceforge.net] 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.

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.

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.

I think the big challenge in open source today is enabling the *easy* interaction between developers and users. The interaction right now is just too costly for both parties. My cut would be that there needs to be further development of automated system slike Mozilla's talkback and that this type of bug reporting should become a *fundamental* aspect of Open Source Development. The current problem with talkback is that it only works for crashes. It would be nice if you had some sort of built-in interaction recording functionality that would allow people to click a button to send a brief playback along with a description of what they did not like.

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?

In most cases, the version of an open source
package you get from Redhat or Debian (or
whoever) does not directly correspond to
the official release of an open source
project. As an extreme example, Redhat
for several years shipped a version of
gcc that ID'd itself as "2.96" while all the
while the gcc developers were swearing up and
down that there was No Such
Thing as GCC 2.96 [gnu.org].

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.

Personally, I've had loads of success submitting bugs for Mozilla. Since I've been using it for my day-to-day work for so long, I decided a lon gimte ago that I could at least bother to report the problems that I find. And the developers have been incredibly responsive. Sometimes they don't agree with me on how it should actually work, but they respond quickly and are willing to discuss the reasons behind their decision, which is good enough for me.

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.

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 [tigris.org]) also support import of Bugzilla's XML format for bugs.

I'm the lead developer of the net-snmp [net-snmp.org] 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 [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!

It is interesting to see some of the replies from people about software they did not pay a dime to get, and yet expect full support (no, I'm not talking the person who asked the question).

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.

They probably have one on the project's web site, one on source forge, maybe one on Fresh Meat, etc. Just pick one of these ones that are associated directly with the project and they should be able to find it.

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.

Well no shit! I hadn't looked at it that way but you're right. There isn't any obvious way for joe consumer to report anything about a Microsoft product.

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.

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.

...and registration passport technology. It is inefficient to register an account for each single project.

...and people may not want any old random idiot who got an account on FooProject's Bugzilla filing bugs in theirs. And I may not want my Bugzilla password, which I use to administer Bugzilla, being made available to other sites in case I want to authenticate against them:-)

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.

5.submit bug to displayed email address.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 vendor8. 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.