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.
some of these packages have zero bugs,
Many eyes makes bugs shallow. The cathedral is inferior to the bazaar.
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. ;-)
Why would you file a bug report when you have the source code to the app? Just fix it yourself and be done with it.
(moderators : this is known as sarcasm)
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
Call me crazy, but what the hell does this have to do with HP?
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?
Why not just submit it by whatever means you find? Anyone who is going to work on the code will know of each place to look for bug reports and they will find it.
FoundNews.com - get paid to blog.,
...in the name of chthulu, did this story get the hp icon?!
would be to check the README many times there is instructions there on where to stubmit bug reports.
The threads grow so quickly these days, don't they ? *sniff*
you know, sometimes it's good just to sit back and think of apples and stuff.
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
This was posted under HP.
-- Is "Sig" copyrighted by www.sig.com?
You're looking in the wrong place. Check the "Feature List".
yeah, but there's no quality trolling anymore. Let's push things forward !
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.
By the time a non-technical user figures out how to submit a bug report, the bug has already been fixed by the more technical users. (Besides, open source doesn't have bugs anyway. ;-)
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
Always goto the developer. If you have to, just email the developer and ask where to submit bugs. Remember that RedHat is most likely not going to fix a bug themselves for say, gaim, unless there is a large vulnerability or something that requires an immediate patch, and the developer is unable to be contacted. In saying such, most (large) projects have a link on their website to a bug database, mailing list, or are hosted on sourceforge.
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
post some guidelines, yo.
1) just because you submit a bug in open source code doesn't mean it will EVER get fixed. Open source developers often have other things they must do to earn a living.
2) If you want good response and professional treatment, pay for a support contract with a reputable company.
Otherwise you get answers like the ones on Slashdot - completely useless, most often insulting, generally caustic, and totally pompous!
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.
I would say mozilla is the poster child of bug submission and feedback. I believe the number of bugs you find in a project's bug list is in direct relevance to the way that the project members respond to bugs. bugzilla at mozilla is very responsve. Enter a bug and within hours you will get a feedback. On the other had there are projects where the team is not as responsive. Peng being an example. I posted queris to the forums, posted it to the deleopers, did not get any useful response, which makes me very less likely to sumbit a Peng bug again. Rather use google (geek's best friend) to find a solution. I guess Redhat's team does not respond to users or they have not advertised it well enough. I came to know about it from this article. There is also an aura of hostility that is widespread among OSS developers. Or this is the way users think they are. I have a few friends who had a hard time getting help for other stuff that they needed. Another aspect is that the users of OSS are themselves geeks and techies, so they figure out the problems and do not bother entering bugs for simple things. Sometimes they make a web page out of it somewhere....
http://www.ajaygautam.com
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
How does a non technical person submit bugs? They dont! They stick with Windows and live like trolls! Like me!! Look, I'm trolling!! BWAHAHAHAH!!
Yes, thats a joke.
This is my sig. Its pathetic.
this is supposed to be a troll.
redhat is the sucks!
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.
At least you're honest.
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".
Now this one's surely a bug .. it has an HP icon wherein there's not even an HP mentioned in the article.
Hmmm, where can I submit this bug?
You're probably not even finding real bugs.
Guidelines to being a successful /. troll
1. There must be at least 2 goatse related posts.
2. There must be at least 2 on how Slashdot sucks in some way.
3. At least one subject line troll.
Feel free to add to these guidelines as you see fit.
A google search of a project I am involved as developer shows (in this order) Debian package, Freshmeat entry, Sourceforge project page, (several other sites follow).
Sourceforge bug tracking service is good, but you have to activate everywhere to have it send you an email for submissions/changes.
An awful lot of sites have forums misleading users that the developers actually read them! (we sometimes find bug reports several months old, including Freshmeat). We tired of submitting where should the users ask for help.
It'd be nice to have all major bug/help trackking sites merge or cooperate. And that would also probably push all those idiotic webmasters away from their forum addiction.
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.
I can't resist a reeeeeeeeply to Salad Shooter.
hello
a/s/l here. Sorry, adding domain tags to your s
Press the action button!
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.
Pussy gets too dry, needs excessive amounts of lubrication.
When I submit bugs to large open source projects, the maintainers usually reply and try to paint it all as my fault, as if I caused the program to do it, or give something with the connotations of "STFU n00b, we've heard that one 1000 times today!"
I'm not alone -- just browse the bug forums of http://www.sourceforge.net and see how many of those maintainer liasons -- especially on a few certain major Open Source projects that I will not name -- simply aren't dedicated to keeping the project bug free, as it seems their philisophy is something along the lines that "bad code is better than no code," as if they were double agents for Redmond or something.
However, the authors usually will look into the bugs if you mail them directly as "URGENT," though it may take a few tries.
Two weekends ago I installed RH7.3 professional (again...as I reverted back to 7.1 for numerous reasons...).
Both times that I have installed 7.3pro, Gnome panel crashes have happened immediately at first boot. This some thing that was never an issue in 7.1.
As annoying as they are to some, submitting bug reports from the consumer end of things, makes me feel like I just add another piece of paper to the endless pile already sitting on some ones desk. But in light of my aversion to bug report submitting, I submitted one this last time. I received my confirmation and all that, but I still really want to know if what I submit as a bug report is the actual information needed to view and see the problem as it occured.
In theory, it's to be like that, right? Or is it like I really thought...just another message clogging some ones Inbox?
In the past core dumps were used, what happened to core?
a/s/l here. Sorry, adding domain tags to your s
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'.
Will Code for Sig
Anything will help
God Bless
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.
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.
mantis.sourgeforge.net is a strong alternative to bugzilla. Bugzilla still lacks a offline client and registration passport technology. It is inefficient to register an account for each single project.
Bugzilla looks ugly and is no software for endusers. Even worse there is no free project that hosts Bugzilla for small projects without an own server. Sourgeforge Bugreports are not state-of-the-art and too slow.
For the
:P
love of
God, why
post your
comment
with hard
line breaks?
I'd imagine everyone has a broswer capable of wrapping lines by now, and if not, they deserve everything they get. Your post looks like complete shit on 1600x1200, which is a shame, as it's pretty accurate and to the point.
Just be glad I don't have mod points
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
oh kinda like how i just recv'd this error message a few minutes ago:
Maximum Comments Exceeded!
You've reached your maximum number of comments you can post: 542 comments over 4 hours.
Note: chances are, you're behind a firewall, or proxy, or clicked the Back button to accidentally reuse a form. We know about those kinds of errors. But if you think you shouldn't be getting this error, feel free to file a bug report, telling us:
Your browser type
Your userid "666"
What steps caused this error
Whether you used the Back button on your browser
Whether or not you know your ISP to be using a proxy, or any sort of service that gives you an IP that others are using simultaneously
How many posts to this form you successfully submitted during the day
Please set the Category to "Formkeys."
Thank you.
Large print giveth, and the small print taketh away
btw, what's up w/ slashdot today? i know they were moving to a new version of the code and they also were moving servers from east to west coasts. other than that, i'd like to know what the hell is going on... anyone know? thanks :)
Large print giveth, and the small print taketh away
So /. is gonna pick on Open Source, where at least there *is* a process?
Whoring for posts again, Taco?
For shame, for shame...
'course that's nothing new.
t_t_b
I'm on PJ's "enemies" list! Are you?
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."
-PUSH-
/. were the new kid on the block, this might make sense for building momentum. However, a mature and respected community can fix its sights on higher goals. It would go well with the new cluster.
Maybe I've spent too much of my life programing in Forth, but it seems odd that slashdot would still encourage the first posters. Keeping the swiftly written and lightly contemplated response at the top of page one discourages others from pushing a well thought and knowledgeable response onto the bottom of the stack's third page.
Why are you afraid to invert the order and display the last post first?
If
-POP-
Anyone got a better suggestion?
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 installed MDK 9.0 on my machine, and have found a bug in top. Read the top man page tells me the maintainer is procps-bugs@redhat.com is the maintainer, whose e-mail bounces.
Ideas?
www.jackasscritics.com
How hard was this? For non-gui, 'man ' or 'info ' usually produces the same results.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
4. Submit the report with the command: mv /dev/null
?? error: file exists
I think you might mean to cat the file?
I'd like to report that this story has a headline Icon of "HP", though perhaps "Shadow Man" would be more acurate.
LINUX: It's cheaper than Water and half the calories
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
What are the best frontends to gdb for non-programmers?
(Oh, and has anybody fixed it so Bugbuddy will handle smtp?)
I often would like to post a bug, but then,
when I get to sites like mozilla's bugzilla,
and i first have to set up an account etc.
and go through bug lists etc. and it takes
an hour before i can send my bug report, i'm
discouraged and i don't do it any more.
i'd much prefer to just send a bug report
without having to have an account and go
through that time-consuming shit.
now of course, this would take more time
from the developers or bug report reviewers,
who would have to sort more reports themselves,
and that's why they don't do it.
could any one come up with an idea to have a
no-login quick bug report sort mechanism that
allows both bug reporting users and developers
/ reviewers not to lose time?
WTF does this have to do with the HP logo?
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
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.
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! :)
DO NOT REPORT BUGS. REPORT FIXES.
STOP COMPLAINING AND HELP THE WORLD INSTEAD
If you submit a cogent bug report, with a test case,
AND INCLUDE A FIX, I assure you the developer
community will stop, look, and listen.
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!
Read the parent, and mod it down, as it gives exactly the advice to hurt both the recipient and the Open Source project it's applied to.
Troll or negative astroturfer, don't know which.
From the update:
It is currently 6:15pm PST on 10/31, which means it should be 9:15pm on the right coast, still 10/31.
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.
No kidding
We get several reports every day consisting of
stories such as:
Well, I was using your stuff, you know, and then
I took my break, and then I clicked on a gaming
site, and, you know, I got an error
You really need to fix your software!!
We can't do anything without the exact error output.
On top of that, a test case would help kick things off.
For sure - we are jaded. Developers get tired of
listening to blather from users who can't describe
what they were doing - let alone produce a test
case or a succinct narrative of how to reproduce
the problem.
We have plenty of real, reproducible bugs to fix-
why waste time fishing after some 'story' report?
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!
What do you do when you've spent a week FIXING several bugs in a low interest SourceForge project and the petty dictator running the project will not commit your fixes? How can you vote such lazy assed maintainers off of SourceForge who are not carrying their weight? If you raise a fuss in the mailing list then YOU appear to be the one that's a dick. And if you're going to say maybe my changes weren't good enough - forget about it. That ain't the case at all. The project has been idle and in a not working state for over a year. The fucking thing cannot even compile without several patches! The maintainer in question was not the original author of the LPGL'd code - the author quit the software business. The current maintainer simply posted it to SourceForge and took a hatchet to it.
If redhat packages a piece of software, all too often they make local changes, add new features to it, create their own version numbers that conflict with the real author's, etc. This is very annoying and problematic for authors, since if someone reports "foo doesn't work" then frequently it is the packager's broken patches or features that are the problem.
It is a support nightmare to create a product foo, then have redhat come along and package it up along with a half dozen other different products and still call it foo.
There are all too many package maintainers out there that want to setup packages the way _THEY_ like them setup, despite the fact that most users don't like them the same way and the real author doesn't either.
No, redhat is far from alone in doing this.
Didn't Bill Gates say that one or twice or three times as a justification for releasing early. So what is the difference.
?
All else fails google it of course.
The fact that "google" could be used as a verb definitely says something about what an influence the Google search engine has on the internet.
I have had several good experiences with Debian. Last January, version 22.1 of lilo came out with some changes that broke on my old hardware. I filed a report through the Debian Bug Tracking System. The Debian maintainer, Russell Coker, contacted me with some questions and suggestions. After a few tries, he put me in direct email contact with John Coffman, the upstream maintainer of lilo. He in turn asked questions, made suggestions, and found a solution. He then suggested I try the beta version of 22.2 from his own site, and helped me use some test software he had developed.
My role was to stick with it, try every suggestion, and send all requested output back to John. In the end, I had a working system, and lilo could handle a few more machines with quirky hardware.
I don't program, but I felt really good about my contribution. So report the bugs, but don't stop with just getting your own problem solved. Sending that extra information back to the maintainer helps him improve the software and makes life easier for other users.
On the other hand, I felt really lucky that both Russell and John were interested in me and my problem. Neither one was just trying to get rid of "the common user"; both were working to make free software better, and I was happy to do my part.
I really like the idea of us end-users submitting bugs and so helping the development of all this wonderful software (mozilla, openoffice, eclipse, etc). Currently there is just one thing that prevents me switching from MS Office to openoffice: a bug with the openoffice and Matrox dual-head [http://www.openoffice.org/issues/show_bug.cgi?id= 3428]. (Basically some of the program's menus are centered with the Matrox quickdesk utility and every menu appears always at the first display even if the program window is at the second display). I have previously submitted a few bugs about Mozilla and even managed to get one fixed, so I should know the basics of bugzilla which is also used by openoffice.org.
Ok, so I tried to get this one fixed also. I tested and tested the various situations that caused misplaced dialog boxes and menus. I even searched the Matrox's forums for more information. Then I tried to submit the extra info to the bug 3428...
The horror! After registering to buggzilla, joining to various developement projects, waiting to be accepted as a member of those projects, and a dozen "You aren't authorized to submit this information" -messages later, I finally gave up. As a result of this it will take a looong time before I'll try openoffice again. I think that there is something fundamentally wrong with a bug submitting process if the average user cannot post his information in a snap. In fact, dumber people (like me) than the average user should be able to submit bugs easily.
(Summary for all bug reporting system developers: please, help us dummies help software development.)
I need to know hot report a bug in Mandrake that causes it to keep cra
[NO CARRIER]
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.
Open a bug with RH against procps then.
Quote the man page and the bounce and suggest
they reopen the address or fix the man page
to say the right place.
Also report the bug itself: if you can get someone
with RH to confirm it, report it there. Failing that,
report it to Mandrake. Distributions do pass these
things around to the person/group whose problem it
really is.
I don't know why a person would sit there twiddling their thumbs waiting for a fix from Redhat. The way I see their errata, they are often the last to know about a problem.
Here is my method:
1. Discover problem.
2. Check for update at Redhat
3. If RH update not available or doesn't help,
look for update at source project.
4. If newer release from source project doesn't
help, check their bugs information to see if
the problem is known.
5. Check their FAQs and support information to
see if anyone else knows of the problem and
a solution.
6. Pursue their preferred method of discussing
potential bugs - mailing list, whatever.
7. Consider workarounds and other packages that
can do the same thing.
In my view, Redhat is simply a delivery mechanism. They are the taxi driver that brings me linux. I don't even think about the taxi driver making fixes to linux. Perhaps that is sometimes not 100% correct, but that is what I assume.
The above would be different if I paid money to Redhat for the package or support. I would engage this while at the same time checking the source of the package if possible.
This totally depends on where you got your version from. - If you got it directly from the developer by downloading sourceballs or CVS export you'll report it directly to the developer's bug tracking system.
If you use the distributor's version you'll simply report it to the distributor and he'll decide what to do with it.
It's all that easy.
Please notice that users should use the distributor's bug tracking system.
Only people who are not clueless will use the tarballs or CVS exports from the developers and should submit directly to the developer's bug tracking system.
This way it all gets filtered at the distribution level because that's where the user got his program from.
A user should file the bugreport at the package in their distribution. If the package maintainer finds this to be a bug in the upstream software he forwards the bugreport (maybee adding some of his own comments) to the upstream author(s).
//fatal
As easy as that, thats how it's done in debian anyway. I don't know about redhat. (Maybee I should have a look at it since I'm currently running RH8).
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.
Have you considered the possibility of writing a script that would query RedHat's bugzilla buglist.cgi nightly, retrieve all bugs for your product, and insert any new ones into your SourceForge bug database? (And similarly for other distributions.)
Good mfences make good neighbors.
If you can't proof read your post here you probably aren't qualified to be reporting any bugs anywhere for anyone.
Perhaps it was a bug in slashcode!
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?
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?
> Only people who are not clueless ... should submit
> directly to the developer's bug tracking system.
This is an example of the general attitude.
I have a BS in applied physics from an Ivy League school, where I also took a few graduate physics courses. I have had people refer to me as "Dr" thinking that I had a PhD. The number of programming languages I've learned is well over 50, the number of machine languages I've programmed in numerically is I dunno a half dozen, in addition to some hardware interfacing I did in school. I've published commercial software, in some cases single-handedly, for decades. In some cases they got top-scoring reviews in national magazines.
In other words, I am not "clueless".
Nevertheless, the source for an entire Linux distro overflows one CD, and as miraculous as it sounds, I just haven't had time to read the whole thing. For most Linux software, I must be considered a mere "user", sometimes spelled by your kind as "luser". I do not understand all of the technical issues of all of the software I use, I cannot definitively isolate the source of a particular bug, and I cannot debug it all myself. In the few cases that I care about, I usually don't have time to file a detailed bug report - you're lucky if I report anything at all.
OK so if you can refer to me and my kind of people as "clueless", that lets you off the hook when you ignore my bug reports, right? In other words, you won't fix any bugs unless it's found by you yourself or a very small circle of insiders who understand the ins and outs of your particular piece of software. And you won't change error messages that are meaningless to me because they refer to these insider concepts.
And you think that Linux is going to make it on the desktop? And you're surprised when Microsoft eats your lunch and Apple swoops down and steals the alternative desktop market out from under you in two years flat.
Marketing-driven companies end up over-marketing their products. Engineering-driven companies end up over-engineering
> because they can't waste their precious time doing a little research...
I found the above statement interesting too. However, I thought the response might be a little bit harsh.
> "You must remember, they're doing you a favor by reporting a problem with your code. keep that in mind."
Isn't the application developer doing to application user a favor by letting them have the software for free? There are a lot of favors to go around, but it seems to me the goal is to get better software. Maybe the person who discovered the bug isn't great in submitting in-depth, concise, and effective bug reports. Whether they have a willingness or capability to improve that skill, they'll never get the chance if 1) developers can't effectively interact with the novice, and 2) there is no effective way to get the bug to the developers. This topic originally started with the discussion about centralized/distributed bug reporting (i.e. getting a gaim error from RH to gaim developers). It would be nice to track the bugs, even if the reporters aren't as helpful as they could be.
Your cluelessness depends on your insights into the program you're submitting the bug for and not your education or other things you did in your life or list on your CV.
It's all not about reading the source. That's completely unimportant for just reporting the bug. But you have to know the program. There are too many bug reports filed by people who could be solved by reading the fine manual. (as they say)
To be honest with you, I don't care if Linux ever makes it on the desktop. What I care is that software works for me. It's not interesting if it was written by Microsoft, Apple, or some random geek who just happened to learn C yesterday. (Which doesn't mean that there aren't people at Microsoft or Apple that just happened to learn C yesterday...)
In another one of your posts you say that your time is valueable. You wouldn't guess it but other people's time is also valueable and if you want to get a bug fixed you should try to write good bug reports that are easy to understand and don't require multiple emails to be sent back and forth.
If you don't want to "know" the program and just want it to work for you then please don't contact the developer but submit a bug report as vague as you like to your distributor's bug tracking system and, depending on the distributor, they'll be happy to help you for a fee or even for free.
It all comes down to this: If people are not paid and do stuff in their free time and you want something from them, then you have to be polite and don't give them the impression of wasting their time.
Test message. This has been the top message on Slashdot.org for me for the past two weeks.
Obviously brak.slashdot.org hasn't propogated to my DNS yet as the new server for Slashdot.
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.