Re: Curating old dists on CPAN
Hi Shawn, On Thu, 30 Apr 2015 20:06:10 -0400 Shawn H Corey shawnhco...@gmail.com wrote: On Fri, 01 May 2015 09:02:08 +1000 Dean Hamstead d...@fragfest.com.au wrote: Emailing the authors of modules who's last release was 10+ years ago seems like a sensible first step. Especially if there is a clear list of next steps (i.e. give it up for adoption). Possibly this should be a normal part of PAUSE. I haven't touch my modules for a long time; it might be 10 years. :) According to https://metacpan.org/author/SHCOREY their latest releases were on August 2009 - so about 6 years ago. They just work. So far, the only bug reports are that they don't work with v5.6 and I'm too lazy to fix them. In that case, you should either fix them on perl-5.6.x or alternatively set a minimal version of perl in META.yml/the code (use 5.008;) / etc. This is also mentioned in the optional Kwalitee tests here: http://cpants.cpanauthors.org/author/SHCOREY This is also of relevance to this discussion: http://perl.plover.com/yak/12views/samples/notes.html#sl-9 Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Buffy Factoids - http://www.shlomifish.org/humour/bits/facts/Buffy/ NASA Uses COBOL. — http://is.gd/ClKAz5 Please reply to list if it's a mailing list post - http://shlom.in/reply .
Automated old dist warnings, Re: Curating old dists on CPAN
On Fri, May 01, 2015 at 12:37:26AM +0200, Leon Timmermans wrote: On Fri, May 1, 2015 at 12:10 AM, Neil Bowers neil.bow...@cogendo.com wrote: I think we should either remove very old dists from CPAN, or update them to follow modern conventions (so they have a META.yml or META.json, for example). [...] There is a third option, which fits better with Leon's view Unless it's actively standing in the way (e.g. dysfunctional yet first hit on a realistic search query), I do not see any benefit to doing this. To the extent that old dists' non-compliance with modern standards can be detected automatically from the contents, Tools can be updated to a) demote search results and b) make it clear to potential users what the problems might be. This approach is extensible as standards develop, without having to revisit each dist Where people think dists shouldn’t be removed, I’m happy to try adopt them to release minimal updates, where I’m able to. Thanks Neil, for this generous offer. -- Matthew -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: Curating old dists on CPAN
On 4/30/2015 5:10 PM, Neil Bowers wrote: I think we should either remove very old dists from CPAN, or update them to follow modern conventions (so they have a META.yml or META.json, for example). I had email with the author of CGI::Response (last released in 1995) for example, and he agreed that it should be removed from CPAN. I had a look at all the dists that were last released in 1995 and wrote up my thoughts on them: http://neilb.org/2015/04/30/curating-old-releases.html Where people think dists shouldn’t be removed, I’m happy to try adopt them to release minimal updates, where I’m able to. I’m interested to hear what others think. Neil This brought back some frustrated memories. I tried to take over Math::Brent, for the purpose of upgrading the package and fixing an error. I managed to locate John Williams, who was fine with it -- but who then couldn't grant me co-maintenance because PAUSE didn't have him as the owner (I checked, and all of his modules at that time were co-owned by another user, although only one had been worked on). At that point he didn't feel like proceeding further, and I didn't feel like making an issue of it, especially if the other user was going to make the fixes anyway. It's now two years later. The other user doesn't seem to have ownership anymore, but Math::Brent is still has an outstanding bug. I'm still interested in being a co-maintainer. For that matter, I'd be interested in co-maintaining Math::Fortran and Math::Derivative, although I would probably retire the Math::Fortran name for something like Math::Util. -john
