in reply to Ninety Day CPAN De-List Proposal
Share your thoughts, please
So if I change email provider, but haven't yet gotten around to updating my email at CPAN (a service where I don't expect frequent, if any, emails to come from) you want CPAN to delist all my modules?
So if I have linked my CPAN distributions to an issues-tracker (either rt.cpan.org or github issues or other appropriate tracker), and don't want to list a valid email on CPAN for spam harvesting, you want CPAN to delist all my modules?
And, by the way, I don't think you have to make your email public in your CPAN profile (though maybe if you do that, it just shows your cpan.org address? I know that's what I have publicly visible, but it's been a while since I set it up); and I don't remember seeing an email-the-author link on most distribution pages. Are you talking about the emails that show up in the AUTHOR section of the POD? If that, so you expect that an author will make a new release of all their distributions if they change their email address, even when they don't have any code fixes?
And even if a module isn't being actively maintained, it can still be of great use to many people, so delisting it just because you cannot get an email through to the author seems rather an overreaction.
All-in-all, your "solution" causes a lot more problems than you think it solves.
The first line of getting help or making suggestions is to look for the Issues link at the distribution page on metacpan.org. If there isn't such a link, see if the Repository link has an attached issues page.
And if the author is unresponsive, and you or someone else wants to be able to take over responsibility for that module, there is a well-defined process, as described in the "take over" section of the PAUSE documentation and in perlfaq7, rather than just arbitrarily hiding/removing their previous work from CPAN.
So, IMO, you are proposing a bad "solution" to a problem whose reasonable solution is already implemented and publicly documented.
|
|---|