Slashdot Mirror
Submitting Bug Reports To Open Source Projects?
aldheorte writes "After installing Red Hat Linux 8.0, I discovered some minor bugs. Some of these are with software actively maintained by Red Hat (e.g. redhat-config-date), but some are not (e.g. gaim). Although it is possible to enter bugs for any package at Red Hat Bugzilla, some of these packages have zero bugs, which probably indicates this is not a preferred method of receiving bugs for that project. In fact, I've found this to be the case for for several project. I find no listed bugs for Red Hat's Bugzilla and a whole database of bugs at another site, such as SourceForge. There are many distributions and channels for open source projects to reach the end user, so how do users, especially non-technical ones, effectively submit bug reports to the right database? How do open source projects make it easier for users to submit bug reports and consolidate the bugs in a single database?" Update: 11/01 11pm EDT by C :Don't know why this was sitting under the "HP" topic, so I've changed it to something more appropriate. Sorry if this has resulted in any confusion.
So they don't *want* to make it easy for you.
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. ;-)
This story has the HP logo for an icon, while it's not about HP at all.
I suffer from attention surplus disorder.
read the man pages. usually there's contact info for the maintainer of the actual program. also, always file the bug with your vendor as well, so they have a chance to upgrade their shipping versions.
-BlueLines
--BlueLines "The cost of living hasn't affected it's popularity." -anonymous
Well, the bug should be filed with the person with whom the responsibility lies. Examples:
Redhat configuration utility: Redhat
Gaim: Gaim
Gaim packaging by Redhat: Redhat
Gaim packaging by gaim: gaim
(I don't know (or care) who makes the RPMs)
The only problem is a conflict.. say... gaim doesn't compile with, say, GCC. Then, the task would be to determine if gaim is non-compliant, or if gcc is non-compliant (or both). In that case, if I don't want (or don't know enough) to track it down, I'd file both.
-- Is "Sig" copyrighted by www.sig.com?
would be to check the README many times there is instructions there on where to stubmit bug reports.
Open Source haqs no bugs, unless the user is an ingrate freeloader who refuses to fix them.
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.
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.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
From what I've heard from the Red Hat folks, their Bugzilla is *definitely* the preferred way to send them bug reports. And as a user, I've found them good about responding to those quickly.
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.
Speaking only on bugzilla places like Red Hat and Mozilla, 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.
Personaly what I do is I submit a bug report (debian's reportbug) and depending on what the bug is I will also email the person who wrote the program.
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.
Blink
If it's an app you use a lot, it's worth finding their primary bug
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.
Cut that out, or I will ship you to Norilsk in a box.
so how do users, especially non-technical ones, effectively submit bug reports
;)
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
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.
Hey freaks: now you're ju
You ARE kidding, right? I just set up 3 bug db's for project's you're working on. Bet you didn't know that. Bet you never will.
Well you should really be sending your bug reports to HP. That way they'll be fixed....
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!Might as well since we already hear about every minor software release anyway.
Where it == "effectively submit bug reports to the right database". I mean, there is almost as many practises as there is open source projects. Well, sourceforge defines one quite common interface. But still, maybe there really would be the need to create some common "protocol", "method" or "mechanism" or "interface" which would make it easier to deliver the bug report to the correct place. If it made sense and was "enforced" with some well known instance, maybe it could be done. A kind of router mechanism that finds the path for the bug report even if you send it to the wrong place initially. So, basicly we would need another open source project to develop this system, and the resulting mapper would then have to be integral part of the development tools of most projects. Uh oh, at this point I started wondering whether this is understadble or not, but what the heck, let's hit "Submit".
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.
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...
The Right Reverend K. Reid Wightman,
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.
Don't piss on people when they are trying to help, Gentoo developers
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?
I tried for 5 years to come up with a clever sig...only to realize that I am not clever.
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.
FoundNews.com - get paid to blog.,
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'.
How do open source projects make it easier for users to submit bug reports and consolidate the bugs in a single database?"
:-)
I go to "Help" -> "Report Bug". That's it. Wow, the amazing advantages of an standardizing desktop system
In this case it's KDE and it helps me to find bugs.kde.org very conveniently.
Report gaim bugs to the gaim bug tracking 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.
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.
Of course, I'm not an open source developer
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.
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.
Always goto the developer.
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.
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.
Only 'flamers' flame!
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?
Just my two cents,
Bud
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.
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.
"You can never have too many elephants on your team."
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.
. Quit playing Monopoly with Bill. Switch to one of many non-Microsoft products today.
You can't fix it yourself?
Dude, the source is right there...
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?
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.
LedgerSMB: Open source Accounting/ERP
This is extremely bad advice! When it comes to software, you should never GOTO. GOTO is baad, mmmkay?
--
If you moderate this, then your children will be next.
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.
int func(int a);
func((b += 3, b));
Ugh. Bad idea (tm).
The bug may be urgent for you (although in most cases you can find a work-around); it's almost certainly NOT urgent for the author. Don't construe your emergency as my priority.
And definitely don't email more than once: the author will attend to your problem as soon as he can, and no sooner. Probably later if you're pestering him.
That said, I've been lucky enough to have had really great response when I've submitted bugs in open source software. Perhaps I'm just lucky, but let me suggest a few reasons for that luck:
I've always made a point of thanking the author for his work (that is, the software, buggy or not, that I'm running for free and with full source), and telling him how useful it is to me (if it wasn't useful, why'd I care about a bug?).
I acknowledge, before I ask him to do more work for me, that I am asking him to work for free to solve my problem, and I appreciate it and realize what an undertaking it might be.
I try to make it easy for the author to figure out just what I'm talking about, by providing version numbers; descriptions of -- or better -- actual buggy output; my OS and its version(s); program state that appears to trigger the bug; etc.
I take a (cursory, at least) look at the source code, enough to possibly suggest where the problem might lie, attempt some diagnostic if possible, and note that if need be, I'll fix the bug myself (if the source is C, C++, or java). (In other words, I implicitly note that I'm willing to bear the burden I'm asking of him, and also that I'm not completely ignorant about coding.)
So far, this has gotten good response -- as in emails answered within hours, even from authors on other continents, and resolutions in hours or days.
The author of Scintilla/SciTE (an excellent GUI source editor), Neil Hodgson, even went so far as to download updated mouse-drivers to his own box, to better diagnose my problem, and probably spent at minimum four hours on my issue the first night I emailed him. On my part, I looked up some API calls and scanned his code to suggest where the fix might go, and suggested what the fix might be.
With his help, I was able to recompile (his makefile worked right out of the box to my great joy!) my own fix by the next day; he had the fix in with his next regular release.
Albert Faber, author of CDex, was similarly helpful, even though my "bug" hardly was a show-stopper: full song-lyric annotations to playlist text weren't being saved correcly in the local cddb. Herr Faber got back to me in at most a day, acknowledged the bug, and had a fix out in his next release -- and I did little more than make some poor suggestions about what might be causing the error.
I go on at such length, and I apologize for it, to convince you that the best way to get bugs fixed is to step up to the plate and be willing to do your part, while letting the author know that you know how much he has done for you, and how much more he'll be doing if he fixes your bug.
Opinions on the Twiddler2 hand-held keyboard?
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 for an example of an excellent customisation.
Gerv
There are many distributions and channels for open source projects to reach the end user, so how do users, especially non-technical ones, effectively submit bug reports to the right database? How do open source projects make it easier for users to submit bug reports and consolidate the bugs in a single database?
:-)
They all standardise on Bugzilla, and use Bugzilla's import and export (or move) features to move bugs between instances
Other bug trackers (e.g. Scarab) also support import of Bugzilla's XML format for bugs.
Gerv
Look, these "major projects" are getting hammered by clueless dolts who haven't done any research, where a "bug" is something like "The script stops working when I call a function I never defined".
They get jaded. And why not? They are HUMAN.
A while ago, I hit a nasty (for me) bug in PHP 4.x. Basically, if you tried to include a file that wasn't there, the script would halt with an error.
And being that include() is a function, I felt that it should behave like any other, and return a failure code and continue, leaving it up to you to trap the error.
For me this was important, but I had to rally for a while with the developers, and get past the RTFM stuff, and argue my case before they accepted my logic and made the fix.
But they do care! Just understand their situation, and work from there.
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
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! :)
Bugzilla is a nifty tool, but if the users fill it full of crap because they can't waste their precious time doing a little research then Bugzilla becomes more of a hindrance than a help.
/bug/ |z0 a nu fea2ure j00 iz +4|k|n l|k3 u 4i|\|+ g0+z n0 c3n+z!!
Searching for previous instances of bugs on Bugzilla is so haphazard/useless that the only way to be sure that your bug gets reported is to post it and pray that you are not duplicating.
The interface of Bugzilla is *awful*, the search is dreadful and then, when you actually do the work of submitting a bug carefully, its; "SUX 2BU bgz|4h l00zr, your
THEN you get lots of emails from other l00z4az who are submitting the same bug.
The fact that people are submitting the same bug over and over is a clear indication that bugzilla DOESNT WORK VERY WELL, and that it needs to be overhauled from the ground up.
ATH0 Bitcoin: 1DnwFLXczVZV8kLJbMYoheUrpqHesjxrSi
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 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.
Distributions do a great job redistributing stuff, but don't do a great job working with the package authors themselves. The net-snmp package is an extremely hard one to maintain, for we support a really large number of operating systems for code which is very operating system sensitive (the architecture ifdefs in some portions of the code will drive you mad. Trust me.) net-snmp is redistrubuted through a number of distributions, and let me tell you that almost no bug reports get to us that are entered into distribution bug tracking databases. It's a nightmare, and because we can't continously search other bug databases for problems, we frequently are left out.
To make matters worse, the distributions often fix things. RedHat and other RPM packages simply roll their own patches into their redistribution and don't send it to us. FreeBSD has a ports tree that contains patches for projects that the projects themselves may have never seen.
I'll never forget the first time I opend the source rpm of the net-snmp package from redhat. There were 3 patches in it that I had never seen for bugs I didn't even know about. Why hadn't I heard of them? because the RedHat package maintainers didn't notify us that they had fixed something.
Finally, what's even worse is that all of the RedHat source RPMs are GPLed. Our package uses a BSD license and thus we can't pull the patches out of the RPMs and apply them to our source without getting explicit permission to re-license it.
The proper thing to do would be to probably search freshmeat for the project page and look at the documentation. Maybe submit it to both the package maintainer and to distribution maintainer if you really have the time (ha!).
My personal plea to the distribution maintainers: help the package authors out! Please!
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
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.
because they can't waste their precious time doing a little research
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.
Looking for Book Reviews? Check out Literary Escapism.
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.
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.
int func(int a);
func((b += 3, b));
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!
...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".
Not only that, but all too often they make "fixes" locally and never pass them on upstream.
Thanks guys.
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.
It is not the tool, it is the lack of human interaction.
LedgerSMB: Open source Accounting/ERP
I see a lot of those, so much so that I now include an integrated bug reporting plugin in my application.
This has proved to be a double edges sword - on the one hand the plugin ensures I have all the details that I'll probably need of the system, (OS program version, memory size, etc), but it makes it almost too easy to report a bug - instead of reading the fine documentation.
Personally I've spent hours working with some users to fix a bug in my code, and I'm happy to do so .. if I get one person who sees the bug and reports it then it's probably fair to say that 20 people see the bug and uninstall the software, never to return.
If people are greatful for my work/fixes they can reward me if they wish ;)
That's true, sadly. In principle, it should be a good thing to have ones application in a distro, because the number of potential users will be much larger, hence the application more thoroughly tested. In practice, the upstream author typically will not see the bug reports at all.
unless you have gotten permission to do so. It is very distracting and in my opinion rude. Feel free to email him. It may not be as efficient (an email is easy to ignore), but it is a lot more considerate because it is easy to ignore, or postpone until he has time. The developer may _choose_ to provide free support, in addition to providing the free software, but he has no obligation to do so.
If you bought the distribution, the people who sold it to you is as accountable as people who sell non-free software. But please use common sense, if you bought a Red Hat distribution from CheapBytes for US$ 1.99, neither Red Hat nor CheapBytes have much moral obligation to provide support.
ISTR something similar happened with Perl a while back -- someone from (IIRC) some flavour of BSD got in touch with the Perl developers and said "hey, here are the patches we apply to Perl, are you interested?". For the past "n" years, they had been silently applying them and the developers never got to know of the patches previously.
Esli epei etot cumprenan, shris soa Sfaha.
I neither agree nor disagree with your post, but it has been my experience that bugs in a package are a thousand times more likely to get fixed if you submit a patch along with the report.
Yeah, but it would be ugly to write (making sure no duplicates, trying to make sure that we hadn't already solved it in versions that are beyond their released version, yadadada)
Actually, if bugzilla just had the ability to send out mail for any bugs in the system for a given package, that would be very benificial. I want to track everything in "this" package kind of thing. (It has the ability to track individual bugs, but not every bug in a package).
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
From today's Naked PC newsletter, excerpted from an article by Lee Hudspeth "Guidelines for Excellence in a Software Development Team":
***
7. Embrace Bug Reports
Too often, we developers tend to view a bug report as an attack on our work. But I say welcome them, embrace them. A bug report is a learning opportunity; it's a chance to see your code/project and its behavior from a completely different perspective (which is, essentially, what quality control is all about). Make sure staff who directly interact with customers, managers, beta testers, or other developers have strong "active listening" skills and are not prone to defensiveness.
***
~REZ~ #43301. Who'd fake being me anyway?
Point taken, but don't you think when you get the same bug report over and over from different people, that perhaps the workaround or documentation or config or whatever may itself be much of the problem?
~REZ~ #43301. Who'd fake being me anyway?
I've had that experience as a tester, where a design decision was causing problems, and the coder kept insisting the undesirable behaviour was not a bug. And of course we testers kept documenting how it was broken, because as far as we could see, it was!!
FINALLY, after weeks of this, the coder broke down and told us that this problem couldn't be fixed because of something else that fundamentally could not be changed, and would get broke all to hell if the bug were fixed. Oh, well, THAT we can understand. Okay, cool. End of problem.
It would have been so much easier if he'd just TOLD us about the sticking point in the first place, saving us a lot of needless work and himself a lot of needless aggravation.
Moral is, when you get that sort of bug report, be more willing to share your REASONS with your testers. Explain what the difficulty really is. Don't assume your testers are morons who can't figure out that sometimes there are tradeoffs or mutually-exclusive solutions. It's far easier for a tester to accept what can't or won't be fixed if they understand your reasons for the decision.
~REZ~ #43301. Who'd fake being me anyway?
It happens, but there is only so much you can do to make it easier for the users to explain things and point them to the right direction.
For example, my own project has a very extensive user manual, which some people say is the best they ever saw for a open source project. It's over 150 pages long and clearly explains everything you can do with our software. From installing, upgrading, configuration and how to actually use the application. It even has a section on how to use the user interface. It's not written for programmers, but for the everyday user, who don't want to know what makes our software tick, but how to make it tick. Still we get a lot of questions about the simplest things, which are explained in detail. The user just has to open the manual, look in the index for the right chapter and start reading.
The same thing applies to filing bug reports. There is an explaination on the submit form which clearly lists what information we need to solve the problem. Still we get bug reports just saying 'X not work, fix please'. I'm just a programmer, not a mind reader!
Also I started rewriting the titles of the bugreport to make it more clear for the users and nowadays I add the status of the bug in the title, so users can see what is fixed and what is not even before reading the report. Would you submit a report for a bug which is marked as 'FIXED:' and listed on the first page a user sees when he wants to submit a bug? Again people don't read.
Of course we do get useful and understandable reports about real problems. If this is the case I try my best to solve the problem as quickly as possible. But unfortunately there are still too many users who are either too lazy to read or think it's easier to ask than try to find the answer yourself. It not only makes me cranky, but steals time away I could otherwise spend on fixing other peoples problems or spend on creating that new feature everybody is waiting for.
(Yes, I am the AC you replied to, didn't have my login information on me at the time)
That's wonderful that you've documented your project so extensively -- in my mind, that indicates a certain care for how everything is done. If I were using your software, it would incline me to extra care in documenting any problems I found with it.
:)
:)
Sometimes, tho, sheer mass of documentation makes it difficult for the user -- after a certain point, even the best effort can develop glazed-eye syndrome. If you haven't written a condensed or at least a quickstart version, you might find that helps the situation, especially if it references the detailed manual as needed. That makes it less intimidating for someone who is a true user (ie. uses the product but doesn't really understand how it works).
I like your idea for adding bug status to the title -- that makes it more obvious to someone trying to cope with an unfamiliar form (and for some users, bug reporting itself is a difficult concept). And much quicker for the experienced user to skim thru while checking whether their pet bug has been exterminated or not. Of course sometimes a "fixed" bug reappears on another configuration, but that's life
As you say, some people just don't read at all -- I have a mailing list signup page that amply demonstrates that: you have to get past the interstitial page with its big STOP sign, you can't just click and send anymore -- yet I still get people who don't think "this is to SUBSCRIBE ONLY, you cannot send mail to this list" doesn't apply to them! Argh!!
But more often in my experience it's that average users don't entirely understand the language. Imagine if you don't know anything about baseball, how little meaning play-by-play shorthand lingo would have for you, let alone printed box scores! That's how it is for most pure users -- they're often struggling just to translate the most basic computerese into terms they can extract meaning from. Sometimes "this doesn't work" is as far as they get before they're so lost that frustration takes over. (I support enough SOHO clients to have become painfully aware of this.)
BTW you write with a nice clear style, so I expect your users have few valid complaints. And it's absolutely GREAT that you were thinking of real everyday users when you wrote your docs. If more programmers could see their software from the ordinary user's POV, there'd be less hair under everyone's chairs
~REZ~ #43301. Who'd fake being me anyway?
It seems a bit silly to me that you feel like you need to be a nazi about the way people try to help your project. RELAX!
Maybe you should create a web form that makes it easy for people to search the existing bug list and to formulate their submissions properly.
I guess what I'm trying to say is that beggars can't be choosers. If managing the project is so unpleasant to you then quit.
Ranting about how dumb the people who are trying to help you make the product better are is rediculous.
Amazing magic tricks
The audacity-help mailing list is open -- you can post without being subscribed, and we always cc the original sender when replying to bug reports and help requests. Users sending mail to that address don't even need to know that the recipient is a mailing list instead of a single person.