Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Best way to deal with a bug in a CORE Module

by taint (Chaplain)
on Dec 03, 2013 at 04:14 UTC ( [id://1065366]=note: print w/replies, xml ) Need Help??


in reply to Best way to deal with a bug in a CORE Module

While I am quite sure boftx already knows this. It might be well worth repeating, for those that don't, and ask themselves the same question;

From PAUSE

Taking over

So there's a module on CPAN that has a critical bug, lacks some features, or is generally under-maintained and you would like to step in?

It's great that you want to help out and we, the PAUSE admins, really don't want to create any unnecessary barrier to getting involved with an existing module (or distribution) on CPAN. There are, however, some precautions we have to take. The following paragraphs outline the reason for these precautions and the steps you have to take. Please read them carefully.

The majority of modules on CPAN has active maintainers. If the maintainer didn't answer the ticket you created in the request tracker, maybe she doesn't know about the CPAN ticketing system yet? Or she's just very busy this week and will get back to you in due time. The best way of helping out is to talk to the current maintainer about what you can do. Getting the PAUSE admins involved is only a last resort!

In some circumstances, we can grant co-maintenance permissions to you or others if the current maintainer of a module has entirely disappeared. You have to understand that is not a decision we make lightly. We are essentially giving write access to somebody else's work to third parties without explicit consent from the missing author. Since almost all code on CPAN has a free license, this is likely unproblematic from a legal point of view, but any violation of a contributor's trust in the PAUSE/CPAN mechanisms is a serious blow against the work of everybody who contributes to CPAN. For this reason, we try to tread very lightly, make the least possible use of the administrative privileges and attempt to protect voluntary contributors like yourself or the author of the module at hand from any unnecessary burden.

You have to realize that the author has probably invested a signficiant amount of time into writing the code in the first place and then gone through the additional work of making it available to others via CPAN free of charge. Therefore, it is crucial to be very polite when asking him or her for co-maintenance permissions. Politeness, however, does not suffice. Particularly when maintaining a module for which you received co-maintenance permissions from the admins (as opposed to being appointed by the author himself), you are *required* to respect the work and design of the author. A common fallacy is that people think they are much better programmers than their predecessors and that entitles them to judge others code quality and refactor everything. Whether or not your style is "better" is entirely irrelevant as it is not your code. Do not be arrogant, be respectful and tread lightly!

If you published your code to CPAN, then went on a hiking vacation (or to hospital) for a couple of weeks only to see that somebody took over, completely changed the design, and generally wreaked havoc, you would probably be rightfully upset and lose the good will that made you contribute in the first place. In order to prevent from happening, please go through the following steps and remember to be respectful all along:

Use the rt.cpan.org request tracker to submit a bug report. If the module's documentation lists another request tracker, try that instead.

Try to reach the author via mail. At the very least, try PAUSE_ID@cpan.org, any mail address the author listed on his search.cpan.org/~PAUSE_ID page, and any mail address that's listed in his or her module documentation. If there's even a mailing list, don't forget that either.

Search the web for other ways of contacting the author. Send more mail. Try posting in public places such as your use.perl.org journal, perlmonks.org or other forums about your looking for the author.

Wait for *at least* several weeks. Remember, the author might be on vacation, ill, or simply busy.

Always keep modules@perl.org in the picture. Send us a copy of your mails to the author. After a reasonable period of waiting, send another mail to the list explaining how you tried to contact the author and pointing at the proof thereof. Do not forget to include your PAUSE ID and that of the original module author in this mail.

Usually, after all this hassle, we are reasonably quick at assigning co-maintenance permissions, but don't hold your breath, we're only human after all. Most requests won't even get here as many authors who moved on and don't maintain their modules any more are very happy to see them taken care of and will assign (primary or) co-maintenance permissions after you've tracked them down and asked nicely.

Good luck and thanks for stepping up.

This document is mirrored on CPAN as CPAN/modules/04pause.html.

Best wishes.

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;
  • Comment on Re: Best way to deal with a bug in a CORE Module

Replies are listed 'Best First'.
Re^2: Best way to deal with a bug in a CORE Module
by boftx (Deacon) on Dec 03, 2013 at 04:52 UTC

    Thanks for posting that, taint. I am already aware of it, and will probably wind up going down that path as my examination of AppConfig doesn't lead me to think that I can come up with a simple work-around short of applying the patch posted in the bug report.

    If I do decide to follow that path, it will be for the purpose of being granted co-maintainer status for the sole intent of applying that patch (giving proper credit, of course.) I haven't yet examined the other bugs in detail, so I don't know if those are ones that I can deal with at this time.

    It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
      Yea, as noted. I was sure you already knew that.

      As to "Taking Over". Things are beginning to look a lot like your sig:
      "It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.". :P

      But then, again. You'll be a hero in the eyes of all those who have had to mess around with it, in it's current shape. :)

      Best wishes.

      --Chris

      #!/usr/bin/perl -Tw
      use Perl::Always or die;
      my $perl_version = (5.12.5);
      print $perl_version;

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1065366]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (1)
As of 2024-04-19 18:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found