Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Adopting Modules

by jk2addict (Chaplain)
on Nov 19, 2004 at 23:18 UTC ( #409184=perlquestion: print w/replies, xml ) Need Help??

jk2addict has asked for the wisdom of the Perl Monks concerning the following question:

I've decided to adopt a couple of modules from Simon Cozens; specifically Apache::AxKit::Language::XSP::ObjectTaglib and AxKit::XSP::Minisession. I've got a PAUSE id and as far as I know all necessary upload permissions have been changed, but I've never done anything with it. I also own and have been through Writing Perl Modules for Cpan a few times in the past.

What I'm looking for is advice, guidance and any other info on what the commen/excepted/expected practices are for when taking over someone elses module. I would think at the very least I should update it and push up a new version with my contact information in place. Obviously credit needs to be maintained with respect to the original author. What should be changed? What should be left alone?

I'm just trying to avoid incoming flames due to mistakes made in ignorance and not in malice. :-)

Updated: For example, I'd like to get rid of this stuff but I don't want to step on previous toes. Hell, for that matter, I'd like to completely convert it all to ExtUtils::ModuleMaker, it's directory structure, and write some tests. I guess my real question is where do I need to make sure to list the previous author? I'd assume the POD and the Makefile.PL.

Maybe I'm thinking too literally. Afterall, the previous versions will still be available in his author directory.

Update 2: Why in the heck did I put this in meditation?

Replies are listed 'Best First'.
Re: Adopting Modules
by stvn (Monsignor) on Nov 20, 2004 at 04:23 UTC
    Maybe I'm thinking too literally. Afterall, the previous versions will still be available in his author directory.

    Exactly! That is the beauty of CPAN and even more so of back-PAN. This stuff never goes away. It is your module now, if Simon still wanted to control it's destiny, he would not have given it up :)

    AxKit::XSP::Minisession is over 2 years old, as is Apache::AxKit::Language::XSP::ObjectTaglib (which only seems to have been uploaded once). Surely they could use some really basic updating to start with. For instance converting the test.pl file in Apache::AxKit::Language::XSP::ObjectTaglib to be a proper t/ file which uses Test::More. AxKit::XSP::Minisession does not even have tests, so adding even just a smoke test to check the module compiles would be a step in the right direction. And of course this is also an opportune time to add your contact info and small paragraph stating that you are now maintaining this module. You can even put a TO DO list or FUTURE PLANS section to let possible users of the module know what you are thinking.

    Personally, I see no problem with "the release early and release often" approach when using CPAN.

    As for the stepping on toes thing, don't worry about it. Anyone who flames you for adopting, maintaining and updating a CPAN module is clearly an a**hole and should be ignored as such.

    -stvn
Re: Adopting Modules
by jZed (Prior) on Nov 19, 2004 at 23:55 UTC
    If a complete overhaul of the module will take a while, you should probably release a new version with your contact info now even if you have only minor changes to make to the module. You'll also want to make sure that the rt.cpan.org rights to the module get transferred to you so that you can examine existing bug reports and begin to recieve new ones.
      Hmmm. I would think they have already, but I guess I'll find out. I'm not sure what magic modules@ has performed thus far. What's the best way to check that?
Re: Adopting Modules
by TStanley (Canon) on Nov 19, 2004 at 23:41 UTC
    I would include a small section in the pod and in the readme stating that the original code was the idea of the previous maintainer, but that you are the new maintainer, and that any questions/bug fixes should be directed to you.
    And I do agree with your notion of giving it an overhaul and putting it out with your contact info.

    TStanley
    --------
    The only thing necessary for the triumph of evil is for good men to do nothing -- Edmund Burke
Re: Adopting Modules
by dragonchild (Archbishop) on Nov 20, 2004 at 04:23 UTC
    I'd take a look at XML::Parser and how it does the documentation. It's gone through at least three authors, if not more.

    When I took over PDF::Template, the changeset was nearly 99.9% of the code and the author didn't have time. Now, once you've taken over maintainership, you're the boss. Sure, you definitely have to look at backwards compatibility, but that's true if you originally wrote it or not.

    Writing more tests, adding new build methods, reorganizing the directory ... as long as you're not ripping out stuff just because it ain't yours, I'd say go for it! If you're not sure, ask your users.

    Oh, yeah - make sure you have a mailing list and that you invite anyone and everyone you can think of to be on it. And, make sure that mailing list is prominently listed in the POD. Mailing lists are an absolute MUST when you've got something opensource. GoogleGroups, Yahoo!Groups ... both are excellent free mailing lists. (Perl6 and Parrot both use GoogleGroups, if that tells you anything.)

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Re: Adopting Modules
by rrwo (Friar) on Nov 20, 2004 at 13:09 UTC
    I would think at the very least I should update it and push up a new version with my contact information in place. Obviously credit needs to be maintained with respect to the original author. What should be changed? What should be left alone?

    I recently took over Log::Dispatch::Win32EventLog. I added my name and contact info on the top of the AUTHORS list, but also updated the installation style to work with Module::Build, included a META.yml etc.

    Of course, I took it over to fix some warnings related to newer versions of Perl and update the test suite. (Which led to finding more subtle bugs....)

    I did update the documentation with some things that I thought needed explicit mention, and rather shamelessly added reference to another module I wrote with overlapping functionality to the SEE ALSO section.

    What I meant to do but have just realized that I did not do, was to put a link to rt.cpan.org for reporting bugs, rather than to have people send E-mail to me. That's the best way since there's a list of outstanding bug reports and feature requests.

    I did not remove references to the other authors, since they put a bit of work into the original. Nor did I update the wording on the license.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2022-05-16 08:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (62 votes). Check out past polls.

    Notices?