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 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 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.
  • Comment on Re: Re: What to do when a module is no longer being maintained

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
    We agree more than we disagree. Yes, the new module must be clearly labeled with a name such as BLIPC ("BlueLine's IP Chain") or something like that. Just as we have separate namespaces in XML and Perl, we need them in module names as well.

    Moreover, BLIPC should clearly state what version of the original IP Chain it forked off of. But if BlueLine does the above then I really don't know what he is waiting for. Maybe there is a user today who needs his modified module, and next week will be too late.