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.

7 of 287 comments (clear)

  1. man pages by BlueLines · · Score: 5, Interesting

    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
  2. They Don't/Shouldn't by scott1853 · · Score: 5, Interesting

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

    1. Re:They Don't/Shouldn't by Gooba42 · · Score: 4, Interesting

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

      Specifically I was dealing with MoodLogic (not OSS but useful) support. I unchecked the box that says "change all by artist" and it went ahead and changed all by that artist anyway. When I wrote in, support intentionally misunderstood and told me not to check the box as, obviously I must have done because there was no bug.

      I wrote back in excrutiating detail how I understood the difference between a checked radio button and an unchecked radio button, explained precisely which songs I was attempting to fix and what the fix should have been. I then explained precisely the order in which I hit the buttons with which mouse button, and what state the checkbox was in at the time.

      The reply again assumed I was an idiot and told me to uncheck the box because there was no bug.

      Frustrating as hell to know what you're doing and deal with people who don't believe that you do.

      --
      I just found out there's no such thing as the real world. It's just a lie you've got to rise above. - John Mayer
  3. Call him up, be nice... by dasmegabyte · · Score: 4, Interesting

    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
  4. Observations of a forelorn bug submitter by budGibson · · Score: 5, Interesting

    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

  5. Distro != Open Source Package in most cases by shoppa · · Score: 4, Interesting
    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.

    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.

  6. Submission Guesswork by slobbit · · Score: 4, Interesting

    I agree that it is difficult and confusing often to report bugs. It seems like many reports are either way too detailed or over simplistic.

    I had a bug that was causing me problems printing to a network printer. When I went to submit a bug on the project I scoured the lists. Finding nothing that matched, I submitted my bug, describing my system, program versions, the fact that the exact same setup had worked under a previous version, and what the symptoms were. When I get the info back on my submission it appears that "my" bug had already been described and fixed. The problem was that the original submitter had a programmer's level of knowledge about the problem, and described it in those terms (blah-blah doesn't change blah-blah-blah in blah.cfg), without mentioning the symptoms the enduser would experience.

    I don't know what the solution is; the Buzilla documentation is pretty good about explaining how to submit a good bug report, it's just that many people don't follow the guidelines, then the maintainers just let original description through without editing for clarity.

    Oh gosh, this has reminded me of my many horrible bug hunts on Bugzilla. What a great topic for Hallowe'en--I'll be awake all night!