Take Back Your Modules!

[markjugg]

This is a public reponse to Ovid's Give up your Modules! post to the Perl module author's list. Several encouraged me to follow up here as well.

I agree with Ovid is that there is a brewing problem with under-maintained modules on CPAN.

Here's my talk, which I walk: Consider yourself an owner of module you use, being considerate that others may feel the same way, especially the current maintainers.

Leave patches in RT. Follow-up on the other bug reports until you reach a resolution with the bug submitter. Ask other bug posters to submit their own patches. If you can't officially close the bug in RT, leave a note that says "I recommend this issue be resolved because..."

Go ahead and prepare a next proposed release with tests/docs/code and ChangeLog updates and tell the author they can simply sign-off on it. If they don't respond or agree, you can still release it yourself.

Remember, open source licenses give you equal rights to do these things.

I now help maintain Data::FormValidator, CGI::Session, CGI::Application, and WWW::Mechanize, none of which I wrote. In these cases, acting helpful and cooperative has been successful. The existing maintainers have been appreciative of my pro-active approach. Further, I have been successful in sharing the burden of maintainership by encouraging other users to make complete code/doc/test contributions themselves.

Yes, it may work best if some module authors give up some of their modules. By acting like a maintainer yourself, you become a logical choice to pass the responsibility on to. Step up.

(If you want a place to start, you could help with the 100 bug reports filed against WWW::Mechanize!)

[rinceWind]

One way to help, which can be useful to authors, other comaintainers and everyone interested in the module(s) is to have a publicly hosted version control repository.

This way, you have a trunk, which is the latest pre-release version of your module; tags trees for your released versions and branches trees for development and major projects. I recommend granting read access to all, but restricting commits to known users via htpasswd.

I have recently set one up for my CPAN modules - mine and comaint. I also have some vapourware modules in there. I am willing to include other modules in there, by request.

http://www.ivorw.com/svn/cpan

If any monks want to use it, drop me a /msg.

You can always set up an SVK mirror for developing modules and patches locally - this is recommended.

[petdance]

I've started using Google's code hosting for my projects: http://code.google.com/hosting/

[Anonymous Monk]

Why (compared to your prevous host)?

[Ovid]

Actually, the situation with Mechanize, while it looks severe, isn't quite as bad as it first seems. Many of those items are spam, many are "wishlist", some are duplicates and some are bugs in external modules over which Andy doesn't have control. It would be nice if they were cleaned out, but in looking them over, it's a much more manageable problem than it first appears.

In any event, thanks for posting this! ++

[geoffleach]

In order to update my (script) submission to CPAN, I need a few fixes to Pod::HtmlEasy. The author is not replying to RT; indeed he appears to have left the community: la.mx.develooper.com replies "<[e-mail]>: Sorry, no mailbox here by that name." So what can be done if there is no author to give up the module?

[szabgab]

If you are willing to maintain it you can start by creating a new release (preferably use a version number with _01 at the end to indicate developer release.) and upload it to PAUSE. In the case of Pod::HtmlEasy that would be Pod-HtmlEasy-0.08_01.

Ask others to test your version of the module.

Then send an e-mail to [e-mail] and ask the admins of CPAN to give you maintainership.

[geoffleach]

Ah! Many thanks.