Forgot your password?
typodupeerror
Bug

Submitting Bug Reports To Open Source Projects? 288

Posted by Cliff
from the getting-your-roaches-lined-up-in-a-row dept.
aldheorte writes "After installing Red Hat Linux 8.0, I discovered some minor bugs. Some of these are with software actively maintained by Red Hat (e.g. redhat-config-date), but some are not (e.g. gaim). Although it is possible to enter bugs for any package at Red Hat Bugzilla, some of these packages have zero bugs, which probably indicates this is not a preferred method of receiving bugs for that project. In fact, I've found this to be the case for for several project. I find no listed bugs for Red Hat's Bugzilla and a whole database of bugs at another site, such as SourceForge. There are many distributions and channels for open source projects to reach the end user, so how do users, especially non-technical ones, effectively submit bug reports to the right database? How do open source projects make it easier for users to submit bug reports and consolidate the bugs in a single database?" Update: 11/01 11pm EDT by C :Don't know why this was sitting under the "HP" topic, so I've changed it to something more appropriate. Sorry if this has resulted in any confusion.
This discussion has been archived. No new comments can be posted.

Submitting Bug Reports To Open Source Projects?

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

    So they don't *want* to make it easy for you.

  • Maintainers. (Score:5, Informative)

    by crimsun (4771) <crimsun@ubuntu.TOKYOcom minus city> on Thursday October 31, 2002 @04:54PM (#4573902) Homepage
    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. ;-)
    • Oops, I slipped Linux in there. Obviously this also applies to the BSDs.
    • Re:Maintainers. (Score:3, Insightful)

      by matman (71405)
      Sometimes, maintainers will even fix the bugs themselves, and work to have the patch merged with upstream source.
  • by orkysoft (93727) <{orkysoft} {at} {myrealbox.com}> on Thursday October 31, 2002 @04:54PM (#4573904) Journal
    This story has the HP logo for an icon, while it's not about HP at all.
    • by IamTheRealMike (537420) <mike@plan99.net> on Thursday October 31, 2002 @06:15PM (#4574585) Homepage
      Reproducibility: always

      Steps to reproduce:

      1) Submit story to slashdot
      2) Set topic wrong
      3) Watch as editors post it anyway

      Actual results: story is posted in the wrong section

      Expected results: story is posted twice, then an editor should apologise

      ---------- Comment by Hemos, 10:05pm

      Dupe of bug #133340985732

      ---------- Comment by CmdrTaco, 10:08pm

      Marking WONTFIX

      ---------- Comment by CowboyNeal, 10:09pm

      VERIFIED

  • man pages (Score:5, Interesting)

    by BlueLines (24753) <slashdot@divisio ... m ['ro.' in gap]> on Thursday October 31, 2002 @04:54PM (#4573905) Homepage
    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
    • Re:man pages (Score:4, Informative)

      by Anonymous Coward on Thursday October 31, 2002 @05:01PM (#4573982)
      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.
  • Ummm... duh? (Score:5, Informative)

    by mikeage (119105) <slashdot@@@mikeage...net> on Thursday October 31, 2002 @04:55PM (#4573919) Homepage
    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.
    • Yeah, but without doing serious bug tracking yourself, it is sometimes hard to figure out which of any number of piece the bug belongs to (distro? package manager? C libraries? actual application? some dependency of the application? ... etc.)
      • Re:Ummm... duh? (Score:3, Insightful)

        by Jason Earl (1894)

        If you aren't willing to do some bug tracking yourself, then why should you expect someone else to do it in their "free" time? If you have a problem with a Free Software package you have one of three choices.

        1. You can try a different package (perhaps a commercial product).
        2. You can pay someone else to fix your problem (RedHat support for example).
        3. You can do some troubleshooting yourself.

        If gaim didn't compile on your RedHat box chances are very good that someone else has also had the same problem. A quick search of Gaim's mailing lists should turn up relevant posts. If no one else has had your particular problem then asking on the list is appropriate.

        My experience with bug reports is that most mailing lists are quite friendly even when a particular "issue" is very well known. They might tell you to RTFM, but they probably will at least point you at the right part of TFM. It has also been my experience that Free Software hackers appreciate your help debugging their software, but only if you actually do the background work. If you expect Free Software hackers to be interested in your bug report you need to be prepared to either give them money or do enough homework so that you are a help instead of an inconvenience.

        • Re:Ummm... duh? (Score:5, Insightful)

          by IdleTime (561841) on Thursday October 31, 2002 @07:13PM (#4574948) Journal
          Not that easy man...

          Joe User BUYS a package with RedHat 8.0 form a computer store. They expect that if they have a problem with a program, RedHat is the correct address for the bug-report. They don't care who wrote the program, to them it is RedHat

          So as you can see, the problem is a little bit more than just blac and white. Most of the posters here think geek and tell you to even submit a patch or a testcase. Joe User doesn't know what a patch or a testcase is.

          In my opinion, the distribution should have a report/search client (webpage?) where Joe User can submit a report like "Uhmm.. Prog X doesn't start when I click on the icon." And don't laugh, this is hte type of problems Joe USer faces and they have no clue how to figure out what is the problem.

          Remember! Linux is starting to hit a usergroup that has very little knwoledge about OS, programming, debugging etc. This is where the support program from the Vendor should take care of their issue.
          • Joe User BUYS a package with RedHat 8.0 form a computer store. They expect that if they have a problem with a program, RedHat is the correct address for the bug-report.

            If he expects this, he probably did not read the lisence argreement. All RedHat (and most other Linux vendor) promise him is limited installation technical support, which means: we'll help you with basic installation of RedHat, and we are not responsible for any bugs, applications not running, or anything else.

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

      Oh, but that's easy! Simply become an expert in whatever language is used, and you can easily file bug-reports :-)

      But seriously, sending to both is probably easier and just as effective if you have made sure it's not reported several times before.

  • A good start (Score:3, Informative)

    by tdmonkey (250059) on Thursday October 31, 2002 @04:56PM (#4573931)
    would be to check the README many times there is instructions there on where to stubmit bug reports.
    • Re:A good start (Score:3, Insightful)

      by micromoog (206608)
      would be to check the README many times...

      Hear, hear. I normally have to read those atrocities of the written word at least three times to make any sense of them. ZING!

  • uh what? (Score:4, Insightful)

    by Anonymous Coward on Thursday October 31, 2002 @04:57PM (#4573948)

    Although it is possible to enter bugs for any package at Red Hat Bugzilla, some of these packages have zero bugs, which probably indicates this is not a preferred method of receiving bugs for that project.

    uhhh.. believe it or not, submitting bugs in Red Hat products on Red Hat's bug-tracking system, is, in fact the preferred method for submitting bugs in Red Hat products.

    Let that soak in for minute.

    Now.. if the bug isn't red hat's fault, you should submit it to the author of the software as well. But since it's red hat's responsibility to put out a working product, you should submit the bug there if you're too lazy to submit everywhere.

    Sometimes packages don't have bugs reported because people were lazy, or couldn't figure out Bugzilla (not exactly the most user-friendly interface), or they used the wrong package or OS version to report it. But when you put a bug in Bugzilla someone will get an email and it will get handled by someone.

    Oh yeah, if you can, FIX the bug and then send in a patch.

    • Re:uh what? (Score:2, Interesting)

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

      Thank You!

      I thought I was the only person who hated Bugzilla's UI. I can use it, but I think it is incredibly messy and hard to use. When I want to do quick searches, I have to pretend to be entering a new bug, since the normal search form has way too many useless details on it.
      • I thought I was the only person who hated Bugzilla's UI. I can use it, but I think it is incredibly messy and hard to use.

        The query page was recently reordered to put the more commonly-used things at the top, and make it more understandable. Have you used the new version (it's been the default on bugzilla.mozilla.org [mozilla.org] for a few months.

        When I want to do quick searches, I have to pretend to be entering a new bug, since the normal search form has way too many useless details on it.

        QuickSearch is also available on the front page :-)

        Gerv
  • by haplo21112 (184264) <{haplo} {at} {epithna.com}> on Thursday October 31, 2002 @04:58PM (#4573952) Homepage
    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.
  • bugzilla (Score:2, Informative)

    by mattdm (1931)
    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.
  • Bugzillas (Score:3, Informative)

    by lunenburg (37393) on Thursday October 31, 2002 @04:59PM (#4573960) Homepage
    Speaking only on bugzilla places like Red Hat [redhat.com] and Mozilla [mozilla.org], any bug you file will generate an email to someone, so that bug report should at least get looked at.

    Of course, with limited resources, they may have to decide how big of a priority your bug is, but you should probably at least try to go through the estabished bug-reporting channels before deciding that they don't work.

    Just because a package has zero bugs reported doesn't mean that nobody looks at those bug reports - it means that no users care enough to file anything on them. Tons of bugs in the "unconfirmed" state would be a better indication that nobody looks at them.
  • by Entrope (68843) on Thursday October 31, 2002 @04:59PM (#4573961) Homepage
    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.
  • Email (Score:3, Informative)

    by fizz-beyond (130257) on Thursday October 31, 2002 @05:00PM (#4573977) Homepage
    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.
  • 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.
  • They Don't/Shouldn't (Score:5, Interesting)

    by scott1853 (194884) on Thursday October 31, 2002 @05:04PM (#4574018)
    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 ;)
    • remotely control the little gnomes in his machine and instruct them to magically fix it
      Why do you use gnomes? I've always found pixies to be much more efficient. Plus they make my software look cooler when it's running.
    • 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.
      • Or in other words... OSS folks don't deal with dumb users, they deal with dumb admins**--who are often flamed away so quickly that only the halfway competent admins remain.

        The original post was in reference to GAIM. Are you telling me you've completely missed all the furvor about Desktop Linux? You don't really think end users are having admins install it do you? Red Hat 8.0 is being touted as their first good step towards Desktop Linux.

        Like it or not, end users coming, and some of them are incompetant, AND want to submit bug reports.

        Please don't flame them and send them back to Windows.

        • The original post was in reference to GAIM. Are you telling me you've completely missed all the furvor about Desktop Linux? You don't really think end users are having admins install it do you? Red Hat 8.0 is being touted as their first good step towards Desktop Linux.

          I was just booted in RH8, and it was a PITA. Sure, if my entire PC was RH it might work, but it isn't.

          That said, Linux is by-nature a thing for "admins", even if it's a lonely amatuer just installing the OS for the first time. They're not a user, they're an admin--and admins should know what they're doing.

          Like it or not, end users coming, and some of them are incompetant, AND want to submit bug reports.

          No end user is without an admin in Linuxland. By deciding to go to Linux, they're either a wannabe hacker or a business choosing the cheaper deal.

          Please don't flame them and send them back to Windows.

          Absolutely not. I plan on flaming red hat for making such an irritating system. (How can the system be HARDER to use than XP? I mean, really!)
    • On the other hand, it helps to have some bug reports. The developers can't test every possible use of their software, and they usually only test it on one computer. As an open source developer, I want to make it easy for people to report bugs so I can fix them.
    • Usually when I get a bug report like that I send an email back politely asking the user for more information. (only 'usually' because if the bugreport was along the line of "your software sucks and you stink and I am going to burn your house down and eat your children" I might have to settle for "civil" instead of "polite")

      Most users, if given explicit instructions, can ferret out enough information for me to determine whether it's a big, a misfeature, an issue, or a non-problem.

      Of course, what often [0] happens with these people is that they never reply with further information and I close the bug after a decent time (a year or two)

      Daniel

      [0] I'd estimate 50-75% of the time.
  • by norwoodites (226775) <`moc.liamg' `ta' `aiksnip'> on Thursday October 31, 2002 @05:06PM (#4574031) Journal
    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.
  • by dasmegabyte (267018) <das@OHNOWHATSTHISdasmegabyte.org> on Thursday October 31, 2002 @05:08PM (#4574052) Homepage Journal
    A lot of these open source projects are maintained by one or two people. Many of them are in the phone book or have an email address lying around. You might as well just contact them directly.

    It's not like the commercial software world, where there may be hundreds of employees and a series of support levels. The developers are all there is, and they may not check all the available bug watch sites because they would rather concentrate on making a better piece of spare time software. Contacting them directly will not only alert them to the error, but probably flatter them as well.

    I got an email a while back from somebody who had been using a freeware encoding translation app I wrote a while back as an essential piece of a corporate mailing package. It was very cool to see how they were using it and how different it was from the original intent. Eventually, I arranged for the fix I suggested and he wrote to go up on the sparsely updated freeware site I had set up at my university.

    Of course, he was willing to fix the bug in this ancient software himself with a little input. If he had come at me with a lengthy email accusing me of writing buggy software or threatening legal action or demanding a fix on code that really was dead to me, etc, I probably would have ignored him.

    By the way, you hit the nail on the head of the anti-OSS argument here. There is really nobody accountable for these bugs, legally or otherwise. You're relying on the kindness of strangers, and if they aren't willing/don't have the time to fix it themselves, you're going to have to pay to have somebody else do it.
    • By the way, you hit the nail on the head of the anti-OSS argument here. There is really nobody accountable for these bugs, legally or otherwise. You're relying on the kindness of strangers, and if they aren't willing/don't have the time to fix it themselves, you're going to have to pay to have somebody else do it.

      Or rather the pro-OSS argument. The alternitive, closed source software, means that you HAVE ALLREADY PAID and have little or no recourse if the vendor does not wish to fix the bug no matter how much you pay.

      Personally I prefer to have most bugs fixed by the kindness of strangers and have the guarenteed option of buying a fix on the open market if that dosen't work out.

    • by jez_f (605776)
      By the way, you hit the nail on the head of the anti-OSS argument here. There is really nobody accountable for these bugs, legally or otherwise. You're relying on the kindness of strangers, and if they aren't willing/don't have the time to fix it themselves, you're going to have to pay to have somebody else do it.

      Relying on the kindness of strangers does not seem like the best idea. BUT quite a lot of OSS developers consider products to be 'their babys' and take some pride in them.

      Some companys support is good and you get good value for money. Others are usesless. It would be nice to see a comparison of the life cycle of an open/closed source bug.

    • the support paradox (Score:2, Informative)

      by Anonymous Coward
      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?
  • by greenskyx (609089) on Thursday October 31, 2002 @05:11PM (#4574075)
    Well you should really be sending your bug reports to HP. That way they'll be fixed....
  • by DeadSea (69598) on Thursday October 31, 2002 @05:13PM (#4574094) Homepage Journal

    You can submit bugs to almost any project with the unix move command (mv)
    1. Make a text file with your favorite editor.
    2. Be sure to name the text file with a good summary
    3. 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
    4. Submit the report with the command: mv <file> /dev/null
    See, its all in one place and its easy!
  • Thus you should always report it to the vendor. Eg. RedHat created many bugs on its own (sometimes I think they added at least as many bugs as they fixed) and the package may be considerably customized or it may not have an upstream maintainer at all. If the upstream version seems to be maintained well, send it upstream too.

    The situation is easier if you have a fix. Then you can look at the source packages whether it's an upstream bug, or a vendor bug. Logically, send the fix to both in the former case, and to vendor in the latter case.
  • by bfallik (561615) on Thursday October 31, 2002 @05:15PM (#4574102)
    Might as well since we already hear about every minor software release anyway.
  • by jukal (523582) on Thursday October 31, 2002 @05:16PM (#4574113) Journal
    Where it == "effectively submit bug reports to the right database". I mean, there is almost as many practises as there is open source projects. Well, sourceforge [sourceforge.net] defines one quite common interface. But still, maybe there really would be the need to create some common "protocol", "method" or "mechanism" or "interface" which would make it easier to deliver the bug report to the correct place. If it made sense and was "enforced" with some well known instance, maybe it could be done. A kind of router mechanism that finds the path for the bug report even if you send it to the wrong place initially. So, basicly we would need another open source project to develop this system, and the resulting mapper would then have to be integral part of the development tools of most projects. Uh oh, at this point I started wondering whether this is understadble or not, but what the heck, let's hit "Submit".
  • by greensquare (546383) on Thursday October 31, 2002 @05:32PM (#4574222)
    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.

    • This [mozilla.org] is why Mozilla kicks ass.
    • You think that's bad, just try reporting bugs for Internet Explorer!

      Not only do they not have any public bug database, but they don't even have ANYWHERE to report bugs to (at least on the sites i've seen) - not even an email address. I eventually sent a report to the "web team", surprise surprise, no response.

      Bugzilla rocks. It's one of the best things about the project.

    • 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! :)
  • by The Man (684) on Thursday October 31, 2002 @05:32PM (#4574230) Homepage
    The rule I always follow is to report bugs in software shipped by a vendor (ie RedHat, Debian, etc.) to that specific vendor rather than to the upstream maintainer directly. This is because vendors often apply their own patches to the canonical sources; these patches sometimes alter behaviour or locations in a way that would make the report meaningless to the authors. Of course, sometimes these patches also add or remove bugs themselves and are often the cause of the unexpected behaviour.

    If a bug is major or affects security I will also mention it to the authors, especially if I'm feeling non-lazy and have reproduced the bug with the standard sources. And, of course, if I am using some software I built myself from the original sources, I will report the bug directly to the maintainer in all cases rather than my distribution vendor.

    As a software author, it's often annoying when a distributor applies patches to software that add, remove, or change feature sets and may introduce additional bugs. Some maintainers will definitely not be willing to help you at all with packages built by others for this reason. Linux is a fine example - try asking sometime about the Red Hat kernel on LKML. Be prepared for flames and/or silence - after Red Hat applies their 500 patches nobody on that list will be willing even to look at your problem.

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

    by Anonymous Coward
    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
    • Re:Forget Gentoo (Score:2, Interesting)

      by lemming552 (101935)
      Hmmm. I posted a bug and got a small progress report. No attitude or anything, but then I found that the bug was more a user error (me) than anything else.
  • by razmaspaz (568034) on Thursday October 31, 2002 @05:37PM (#4574260)
    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?
  • by weierophinney (410749) on Thursday October 31, 2002 @05:41PM (#4574296)
    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'.
  • Ho I do ... (Score:5, Informative)

    by uhlmann (139234) on Thursday October 31, 2002 @05:52PM (#4574386) Homepage
    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 [kde.org] very conveniently.
  • Gaim bugs (Score:3, Informative)

    by Vann_v2 (213760) on Thursday October 31, 2002 @05:54PM (#4574417) Homepage
    Report gaim bugs to the gaim bug tracking [sourceforge.net] at sourceforge. Or, talk to the people in #gaim on OPN. Either way, your bug will get known, and, in the latter case, you might get an answer right away.
  • Identify yourself! (Score:5, Informative)

    by Dominic_Mazzoni (125164) on Thursday October 31, 2002 @06:04PM (#4574504) Homepage
    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.
    • by Reziac (43301)
      Re shutting down your online bug tracker and limiting reports to the mailing list: does that mean that everyone who wants to report a bug must first subscribe to the mailing list? Pretty soon everyone is on a mailing list for every piece of software they ever used!! Argh, my aching mailbox.

      A little overstated for effect [g] but you can see how that would be a problem, especially if someone is strictly a user of your program, and is neither interested nor involved in its development, but was just trying to be helpful by reporting a bug. "Sign up for a mailing list just to report this stupid bug? Forget it!" And maybe you lose some critical insights as to how *average users* are experiencing your program.

      Good point tho, about making sure bug reporters include contact info.

  • go to redhat (Score:3, Interesting)

    by josepha48 (13953) on Thursday October 31, 2002 @06:18PM (#4574610) Journal
    that is what I do. I just file them at bugzilla.

    I feel that if they put it on their cdrom then they should hvae tested it some. They will also know or should know the best way to contact the maintainer. They also may be appling their own patches to the code. They do this in the linux kernel and I am sure that they do it elsewhere, so it may actually one of their patches that caused the problem.

    I had a problem on my system recently where I upgraded from RH 7.2 to RH 7.3 and my passwd file was locked. I removed the .pwd.lock file the ptmp file and any other file that I could think of. I even boot the system into init 1 and init 2 and tried but it was still locked. Then I installed RH on a second drive and booted the second drive and the second system recognized the /mnt/etc/passwd file as still being locked. I thus had to reinstall RH 7.3 wiping out my system. Thank goodness I had mount points from /opt and /home that I saved data on and did not loose anything. I also save important /etc files as well. So it was about 3 to 4 hours to rebuild the system tops from a new install.

    So who is responsible for useradd? For vi / vim? For /etc/passwd? I have no idea, but in redhats database there is now a bug about this as I feel that it is their software at some point.

    • Re:go to redhat (Score:3, Informative)

      by zrodney (253699)
      use strace -e trace=file to run the program, and it will give a
      clue about what file it tried to open when it said the passwd file was locked.

      if you can ammend your bug with that pathname, it may help to fix the bug that you have run across

      you really didn't need to reinstall just to fix that

      • I wiped the system clean and did a fresh install, and do not have that poblem, so it is to late for that. I had done lsof and f to see what had the lock and NOTHING had a lock. It was totally weird.
  • by budGibson (18631) on Thursday October 31, 2002 @06:27PM (#4574663)
    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
  • by shoppa (464619) on Thursday October 31, 2002 @06:50PM (#4574818)
    In most cases, the version of an open source package you get from Redhat or Debian (or whoever) does not directly correspond to the official release of an open source project. As an extreme example, Redhat for several years shipped a version of gcc that ID'd itself as "2.96" while all the while the gcc developers were swearing up and down that there was No Such Thing as GCC 2.96 [gnu.org].

    The degree of divergence between the two determines whether it is appropriate to send the bug report to either or both. In most (but not all) cases the distro will be lagging behind the OSS package bugfixes so it's very likely that it's already been fixed.

    The real solution, of course, is to ditch all distros and build everything from sources yourself [linuxfromscratch.org].

  • by El Volio (40489) on Thursday October 31, 2002 @06:55PM (#4574854) Homepage
    Personally, I've had loads of success submitting bugs for Mozilla. Since I've been using it for my day-to-day work for so long, I decided a lon gimte ago that I could at least bother to report the problems that I find. And the developers have been incredibly responsive. Sometimes they don't agree with me on how it should actually work, but they respond quickly and are willing to discuss the reasons behind their decision, which is good enough for me.

    I've only submitted one bug in a distribution package (to Debian), and I saw a reply as well -- 3 months later. Although I still use Debian, responsiveness is probably not high on the list of reasons I do. Then again, most Debian maintainers are volunteers but a substantial chunk of Mozilla developers are paid, so that probably explains it.

  • by telstar (236404)
    You can't fix it yourself?
    Dude, the source is right there...
  • by Gerv (15179) <gerv.gerv@net> on Thursday October 31, 2002 @08:25PM (#4575351) Homepage
    There are many distributions and channels for open source projects to reach the end user, so how do users, especially non-technical ones, effectively submit bug reports to the right database? How do open source projects make it easier for users to submit bug reports and consolidate the bugs in a single database?

    They all standardise on Bugzilla, and use Bugzilla's import and export (or move) features to move bugs between instances :-)

    Other bug trackers (e.g. Scarab [tigris.org]) also support import of Bugzilla's XML format for bugs.

    Gerv
  • HAMMERED! (Score:3, Insightful)

    by mcrbids (148650) on Thursday October 31, 2002 @08:42PM (#4575423) Journal
    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
  • by hardaker (32597) on Thursday October 31, 2002 @09:49PM (#4575719) Homepage
    I'm the lead developer of the net-snmp [net-snmp.org] package and let me give you my 2 cents on the subject from a first hand view:


    Distributions do a great job redistributing stuff, but don't do a great job working with the package authors themselves. The net-snmp package is an extremely hard one to maintain, for we support a really large number of operating systems for code which is very operating system sensitive (the architecture ifdefs in some portions of the code will drive you mad. Trust me.) net-snmp is redistrubuted through a number of distributions, and let me tell you that almost no bug reports get to us that are entered into distribution bug tracking databases. It's a nightmare, and because we can't continously search other bug databases for problems, we frequently are left out.


    To make matters worse, the distributions often fix things. RedHat and other RPM packages simply roll their own patches into their redistribution and don't send it to us. FreeBSD has a ports tree that contains patches for projects that the projects themselves may have never seen.


    I'll never forget the first time I opend the source rpm of the net-snmp package from redhat. There were 3 patches in it that I had never seen for bugs I didn't even know about. Why hadn't I heard of them? because the RedHat package maintainers didn't notify us that they had fixed something.


    Finally, what's even worse is that all of the RedHat source RPMs are GPLed. Our package uses a BSD license and thus we can't pull the patches out of the RPMs and apply them to our source without getting explicit permission to re-license it.


    The proper thing to do would be to probably search freshmeat [freshmeat.net] for the project page and look at the documentation. Maybe submit it to both the package maintainer and to distribution maintainer if you really have the time (ha!).


    My personal plea to the distribution maintainers: help the package authors out! Please!

  • Free -vs- pay (Score:3, Insightful)

    by Quixote (154172) on Thursday October 31, 2002 @11:03PM (#4576058) Homepage Journal
    It is interesting to see some of the replies from people about software they did not pay a dime to get, and yet expect full support (no, I'm not talking the person who asked the question).

    Compare your experiences with the following:
    We bought a couple of ICP-Vortex RAID controllers (expensive puppies). When we got the controllers, we found a problem: trying to get into their "BIOS" (ICPCON, by hitting ^G) would make the system lockup. Secondly, it required a floppy to upgrade the firmware; we wanted to see if there's a way around it.

    We called Intel (who owns Vortex). The operator says: "fork over $25 before I transfer you to a live person; else go to this URL".

    Not wanting to part with the $25 so soon, we went to the URL. Vortex wasn't even mentioned anywhere. Finally, a colleague sent email to icp-support@intel.com. Waited for a few days, and he got a canned reply ("No").

    But what about the ICPCON question?, he asked. Waited for 1 whole week, and got another canned email, with the wrong answer.

    He has sent email to Intel again. The saga continues.

    The moral of the story: just because its "free", please don't expect better support than you get for software that you paid money for! At least be realistic.

Slowly and surely the unix crept up on the Nintendo user ...

Working...