Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

tsee (4409)

tsee
  reversethis-{gro.napc} {ta} {relleums}
http://steffen-mueller.net/

You can find most of my Open Source Perl software in my CPAN directory [cpan.org].

Journal of tsee (4409)

Thursday December 14, 2006
10:41 AM

What if you find a bug in a module from CPAN?

[ #31915 ]
What do you do if you find a bug in a module from CPAN?

(Supposing it's not your own.)

Personally, I think one should take the following steps:

  • Possibly investigate and come up with a fix if it's not too much to ask.
  • Check the module documentation for suggested methods of bug-reporting and act accordingly.
  • Unless otherwise noted, file a ticket in the RT queue of the module/distribution and take a minute to include all necessary details.

This is really where even most experienced people seem to stop. Unfortunately, that is often not enough. Not all module authors use RT. Some deliberately ignore it, some don't like it, some don't know or understand it. Some have disappeared altogether. If one filed a bug against an actively-maintained module and there was evidence that the author used RT, this would be enough. Otherwise:

  • Keep an eye on the ticket. If it remains untouched for a couple of weeks or months and there are no indications that the distribution is maintained, consider contacting the author/maintainer by other means such as email. Of course, it is important to be tactful. Do not harrass these people. They donated their work and time just as you do.
  • If the author has completely disappeared and the emails bounce, please consider contacting modules@perl.org about it.
  • If it's evident the module is unmaintained, you can then apply your fix (and, if you like, some outstanding tickets) and, with the blessing of modules@perl.org, upload a new distribution to CPAN.

Now, you might say that you don't have the time to do this. Nobody really does. But if you had the time to write a coherent bug report on RT, it would be a waste of your previous effort not to make sure the module actually gets fixed.

Getting in touch with authors can be tedious and time consuming, but most are willing but busy and gladly accept help. If you have a fix, consider donating a couple more minutes to apply it and roll a new distribution.

CPAN is Perl's greatest strength and the abundance and quality of software on CPAN is our best selling point. Let's keep it that way.

Thanks for reading!

Steffen

Update: Now mentioning that it's a good idea to check for the author's preferences concerning bug reports.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I recently took over maintenance of Class::Factory from Chris Winters. I use the module quite a bit, but I got an email from another user of it asking for a feature. What he wanted looked fine, so I handed him a commit bit to the svn repository. Works for me :)

  • The last couple of times I tried to use RT, my ticket was rejected by the system without a good explanation. Plus, that user interface is GOD...AWFUL. I cannot follow what the hell is going on with that thing, and I've used a bunch of different bug trackers, from GForge to Trac to Bugzilla. That thing actually makes Jira look good.

    <sarcasm>Oh, but it's written in Perl, so let's all pretend it's wonderful.</sarcasm>

    After that experience, I decided to just email the authors directly, or sti

    • RT isn't perfect. But it has a few things going for it:

      - It's well-integrated into the other services around CPAN and PAUSE: You get a bug (RT ticket) count on search.cpan.org, PAUSE ownership/maintainership status propagates to RT, etc. That's not easy to do and it can help tremendously.
      - It's free. That is, in terms of Software.
      - It's also a free service in that it's run by volunteers (i.e. Best Practical) on their server with their bandwidth.

      About the user interface: You can report bugs via automatically
    • I agree. I do use RT, but it’s very annoying. Comes with the territory: it’s really a ticketing system, not a dedicated bug tracking system, so there’s a lot of interface clutter.

      The only thing I’ve used that’s worse is Bugzilla. Also written in Perl…

  • I'd say that rather than assuming that you should rt.cpan.org, you should check to see if the module has a SUPPORT section. Personally, I prefer that people use RT for my modules, and my SUPPORT sections say so. But if an author doesn't want to use RT, they should say how they prefer to be contacted.
    • You're right. If the author explicitly says that bugs should be reported in some different manner, we should by all means respect that! (I'll update the journal entry to reflect that.)