Re^2: Upgrade-proofing overridden subroutines

Good point.

Are there many modules out there that:

Have unresponsive maintaners and
Are still actively developed?

In other words, if the module you're working on is so forlorn and forgotten that no one will respond to you, you probably don't need to worry about them changing it and breaking your override thing.

Am I wrong/missing something/snorting glue?

Comment on Re^2: Upgrade-proofing overridden subroutines

Replies are listed 'Best First'.
Taking over broken subroutines?? by astaines (Curate) on Aug 15, 2006 at 18:54 UTC
There is an important issue which goes beyond Ovid's elegant solution. There should be a way to take over deceased modules. Text::CSV comes to mind. Is there any group who would be willing to arbitrate here? -- I would propose that a module could only be taken if the original developer does not reply for a certain period, say three months or six months. Is this a runner or are there insuperable copyright issues? -- Anthony Staines	[reply]
Re: Taking over broken subroutines?? by adamk (Chaplain) on Aug 16, 2006 at 14:13 UTC
The modules@perl.org team (mainly Brian Foy, Andreas and myself) have been handling this for years. Module takeover is handled on a case by case basis, with the general standard being "A number of contact methods tried a number of times over a number of weeks". You'll then be given co-maintainership. If the original author returns, they retain control. Often, they'll just hand you primary if you show an interest. But this is a solved problem.	[reply]
Re^3: Upgrade-proofing overridden subroutines by gloryhack (Deacon) on Aug 16, 2006 at 08:08 UTC
I don't know of a survey that would authoritatively answer that question, but modules do frequently change hands after the original developer loses either the motivation or the time to maintain them. There's often some latency between the onset of neglect and the adoption by a new maintainer, so you can't know in advance what the future of a neglected module might be. I think that if you can't adopt the existing CPAN module yourself, the most bulletproof solution is to roll your own.	[reply]
Re^3: Upgrade-proofing overridden subroutines by DrHyde (Prior) on Aug 17, 2006 at 08:54 UTC
If an author is genuinely unresponsive, asking the modules@cpan mailing list to transfer ownership to yourself can work. That's how I took over Data::Compare, whose original author seems to have fallen off the face of the planet.	[reply]