in reply to Re: What to do when a module is no longer being maintained
in thread What to do when a module is no longer being maintained
Even if you post an updated module and then don't maintain it,
users are no worse off...
The courtesy you're extending in doing a thorough check is not only to the original author, but to the user community in not creating multiple, potentially conflicting versions of the source code base unnecessarily. If BlueLines put out a new version of IPchains.pm and the original author followed a week later with another that contains a different fix or API change, the well-intentioned fixed version has caused confusion in the user community.
This is different from your example of multiple Linux distributions, which are (mostly) different groupings and packagings of established code bases. One of the reasons Linux is successful is because there aren't multiple forks of the kernel source code. And those that variants do exist (for example, Alan Cox' networking code) are clearly labeled, and aren't versioned as another release of Linus' kernel.
So if it's important to make a change available quickly, and you want to push the analogy with Linux distributions, it would be safer if BlueLines put out a distinct "BlueLines" distribution of IPChains.pm in the interim. That would keep the distinction clear (in the same way that Red Hat is Red Hat and Mandrake is Mandrake) while verifying that the original author has, in fact, abandoned it the module. And the variant can be abandoned whenever it's folded into the "official" version of the module, either because BlueLines takes over or because the original author pops up and picks up the fix.
The underlying point remains, though: lack of a reply from the original author a week after sending a message to a possibly out-of-date email address is hardly thorough enough to determine that it's really unmaintained.
The courtesy you're extending in doing a thorough check is not only to the original author, but to the user community in not creating multiple, potentially conflicting versions of the source code base unnecessarily. If BlueLines put out a new version of IPchains.pm and the original author followed a week later with another that contains a different fix or API change, the well-intentioned fixed version has caused confusion in the user community.
This is different from your example of multiple Linux distributions, which are (mostly) different groupings and packagings of established code bases. One of the reasons Linux is successful is because there aren't multiple forks of the kernel source code. And those that variants do exist (for example, Alan Cox' networking code) are clearly labeled, and aren't versioned as another release of Linus' kernel.
So if it's important to make a change available quickly, and you want to push the analogy with Linux distributions, it would be safer if BlueLines put out a distinct "BlueLines" distribution of IPChains.pm in the interim. That would keep the distinction clear (in the same way that Red Hat is Red Hat and Mandrake is Mandrake) while verifying that the original author has, in fact, abandoned it the module. And the variant can be abandoned whenever it's folded into the "official" version of the module, either because BlueLines takes over or because the original author pops up and picks up the fix.
The underlying point remains, though: lack of a reply from the original author a week after sending a message to a possibly out-of-date email address is hardly thorough enough to determine that it's really unmaintained.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Re: Re: What to do when a module is no longer being maintained
by sierrathedog04 (Hermit) on Feb 11, 2001 at 00:52 UTC |
In Section
Seekers of Perl Wisdom