Re: James Freeman's other modules (was: Re: CGI::Simple)
Fergal Daly wrote: Changing the subject from Keenan to Freeman (James Keenan is not MIA), Yes, the reports of my demise are quite premature. Ironically, today we had the first meeting of Perl Seminar NY's Phalanx Phoenix project (http://www.perlmonks.org/index.pl?node_id=586406), whose explicit purpose is to train new maintainers of CPAN modules. And thereby reduce the number of Perl modules abandoned in the future! jimk
Re: James Freeman's other modules (was: Re: CGI::Simple)
On 12 Jan 2007, at 10:58, Fergal Daly wrote: Changing the subject from Keenan to Freeman (James Keenan is not MIA), Ah - I didn't even read the subject :) -- Andy Armstrong, hexten.net
Re: James Freeman's other modules
I was also wondering whether - given that backpan exists so people can always find them if they really want them - there shouldn't be a mechanism for removing modules that are unloved and unused. That strikes me as a little severe. Some may be packaged with OS distributions. Heap::Priority sounds useful, as does Algorithm::LCSS. What needs to be done, and was discussed recently, is have a way of detecting dead modules, based on untaken RT tickets and author uploads. David
Re: James Freeman's other modules (was: Re: CGI::Simple)
Changing the subject from Keenan to Freeman (James Keenan is not MIA), F On 12/01/07, Andy Armstrong [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12 Jan 2007, at 10:16, David Landgren wrote: Do we wait until someone else manifests a need to dust off one of them to hand over maintenance? Or do we forget about it until next time? If it's worth it, then I would volunteer. Actually I was thinking of volunteering for the whole lot of them - but then decided that they're probably not that valuable to anyone. I was also wondering whether - given that backpan exists so people can always find them if they really want them - there shouldn't be a mechanism for removing modules that are unloved and unused. - -- Andy Armstrong, hexten.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFFp2e0woknRJZQnCERAquJAJ4hKkNHZKS3u3JnhRbcPd9k7xUm9wCfaKfK M8tnMc8hzZxL8BlEEyAMtVg= =k1gg -END PGP SIGNATURE-
Re: James Freeman's other modules
Le vendredi 12 janvier 2007 à 14:11, David Landgren écrivait: I was also wondering whether - given that backpan exists so people can always find them if they really want them - there shouldn't be a mechanism for removing modules that are unloved and unused. That strikes me as a little severe. Some may be packaged with OS distributions. Heap::Priority sounds useful, as does Algorithm::LCSS. What needs to be done, and was discussed recently, is have a way of detecting dead modules, based on untaken RT tickets and author uploads. Maybe a yearly email from PAUSE asking them to click a I'm still active form would be enough? -- Philippe BooK Bruhat When you run from your problem, you make it that much harder for good fortune to catch you, as well. (Moral from Groo The Wanderer #14 (Epic))
Re: James Freeman's other modules
On Fri, Jan 12, 2007 at 03:09:00PM +0100, Philippe Bruhat (BooK) wrote: Maybe a yearly email from PAUSE asking them to click a I'm still active form would be enough? I get enough spam already. On Fri, Jan 12, 2007 at 08:07:57AM -0600, Andy Lester wrote: How in the world could you determine either unloved or unused? And unupdated certainly doesn't mean that they're not valuable. It can just mean that they have no known bugs. IIRC MJD cites Text::Template as an example of something that people wrongly assume is abandoned simply because the most recent release is some time ago. Nicholas Clark
Re: James Freeman's other modules
Andy Armstrong writes: For that reason attempting to do any completely automated garbage collection on CPAN would be fraught - but it might be possible to automatically identify modules that /might/ be dormant and then manually sift through them. Trying to change Cpan is likely to be hard: think of who's approval you'd need (technically and socially) and how wide-ranging the effect would be. You're basically proposing a subset of Cpan. Or possibly a subset of Cpan Search. Or maybe a heuristic for putting 'this module seems to be abandonware' notes on AnnoCpan. You can do any of those without the agreement or blessing of anybody else. If your hunch turns out to be correct then your service (or whatever) will turn out to be more useful than the existing one. People will start using it. At that point in can be blessed with more 'official' status. For example, consider JJ's Perldoc project: it's something that he did, and is now running 'officially' as perldoc.perl.org. I guess there are essentially three categories of module 1 active, maintained 2 actively used, abandoned 3 not used, not maintained It'd be nice to be able to weed out some of the modules in category 3 and identify cat 2 modules with a view to flagging them as abandoned so that when/if a new maintainer came along the takeover processes could be fast tracked. Because in your experience of the past week or so the current process is too slow? I'm not entirely sure what problem you're trying to solve here. But that's largely irrelevant -- because however good your idea is, there's bound to be somebody in the Perl community questioning it or objecting to it! So don't wait for approval: just do it, whatever it is, then show folks. Good luck! Smylers
Re: James Freeman's other modules
On 12 Jan 2007, at 15:06, Smylers wrote: If your hunch turns out to be correct then your service (or whatever) will turn out to be more useful than the existing one. People will start using it. At that point in can be blessed with more 'official' status. For example, consider JJ's Perldoc project: it's something that he did, and is now running 'officially' as perldoc.perl.org. Sure - I'm not suggesting anyone else should do this - just floating an idea. I guess there are essentially three categories of module 1 active, maintained 2 actively used, abandoned 3 not used, not maintained It'd be nice to be able to weed out some of the modules in category 3 and identify cat 2 modules with a view to flagging them as abandoned so that when/if a new maintainer came along the takeover processes could be fast tracked. Because in your experience of the past week or so the current process is too slow? Because it's possible I guess. The process of identifying abandoned modules could start before there was a volunteer to take over. I'm not entirely sure what problem you're trying to solve here. But that's largely irrelevant -- because however good your idea is, there's bound to be somebody in the Perl community questioning it or objecting to it! So don't wait for approval: just do it, whatever it is, then show folks. Good luck! Thanks :) -- Andy Armstrong, hexten.net
Re: James Freeman's other modules
On Fri, Jan 12, 2007 at 03:27:04PM +0100, Philippe Bruhat (BooK) wrote: Le vendredi 12 janvier 2007 à 14:12, Nicholas Clark écrivait: On Fri, Jan 12, 2007 at 03:09:00PM +0100, Philippe Bruhat (BooK) wrote: Maybe a yearly email from PAUSE asking them to click a I'm still active form would be enough? I get enough spam already. Could be sent to those authors who are detected as inactive. And when was perl-5.8.8 released? *ducks* *and again* (On the other hand, it is obvious that Acme::Meta is both loved and used, so we can see that Nicholas is still very much active.) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: James Freeman's other modules
On 12 Jan 2007, at 15:55, Chris wrote: So... what does the A in CPAN stand for again? Hang on... It's on the tip of my tongue... I'm not sure how easy it would be to track #3, because people could be downloading the modules from other sites, or in different packaged formats. And I don't understand what the benefit of removing a module would be just because it isn't deemed to be immediately useful. Noise reduction / cage cleaning basically. Everything gets archived in backpan anyway - and I'm not necessarily proposing removing things from CPAN - but if we could add some metadata about whether a module was actively supported that alone might be useful for people. And actually I'm not really proposing anything concrete - just trying to work out how we collectively feel on this topic. -- Andy Armstrong, hexten.net
Re: James Freeman's other modules
Hi, It is important to mention that CPAN is put to use by other things than the CPAN shell and search.cpan.org such as the FreeBSD port system. So at least a few last versions should be always be available via CPAN. Ref: http://use.perl.org/~jonasbn/journal/28503 jonasbn On 12/01/2007, at 17.07, Andy Armstrong wrote: On 12 Jan 2007, at 15:55, Chris wrote: So... what does the A in CPAN stand for again? Hang on... It's on the tip of my tongue... I'm not sure how easy it would be to track #3, because people could be downloading the modules from other sites, or in different packaged formats. And I don't understand what the benefit of removing a module would be just because it isn't deemed to be immediately useful. Noise reduction / cage cleaning basically. Everything gets archived in backpan anyway - and I'm not necessarily proposing removing things from CPAN - but if we could add some metadata about whether a module was actively supported that alone might be useful for people. And actually I'm not really proposing anything concrete - just trying to work out how we collectively feel on this topic. -- Andy Armstrong, hexten.net
Re: James Freeman's other modules
Smylers wrote: [stuff about detecting dead modules] I'm not entirely sure what problem you're trying to solve here. But that's largely irrelevant -- because however good your idea is, there's bound to be somebody in the Perl community questioning it or objecting to it! So don't wait for approval: just do it, whatever it is, then show folks. One thing that makes it difficult to play along at home is that there's no easy way to obtain a dump of the cpan.org RT tickets, short of violently scraping a web server that's already slow enough as it is. If one could obtain a tarball of a tab-delimited file containing o RT id o status o last update o distribution o subject of all tickets, or all non-resolved tickets, well there's a language that's good at munging such data and producing all kinds of interesting reports. Is Jesse Vincent the person to ask for this? David
Re: James Freeman's other modules
David Landgren wrote: One thing that makes it difficult to play along at home is that there's no easy way to obtain a dump of the cpan.org RT tickets, short of violently scraping a web server that's already slow enough as it is. If one could obtain a tarball of a tab-delimited file containing o RT id o status o last update o distribution o subject of all tickets, or all non-resolved tickets, well there's a language that's good at munging such data and producing all kinds of interesting reports. Is Jesse Vincent the person to ask for this? AFAICT, he is. But asking your question at cpan- [EMAIL PROTECTED] is probably the best thing :-) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: James Freeman's other modules
On Fri, 12 Jan 2007, Andy Armstrong wrote: Noise reduction / cage cleaning basically. Everything gets archived in backpan anyway - and I'm not necessarily proposing removing things from CPAN - but if we could add some metadata about whether a module was actively supported that alone might be useful for people. I'll agree more metadata would be helpful, especially if it was meaningful. I'm guessing part of your goal is to improve CPAN searching, which could use some improvements (the search part, not the goal part). And actually I'm not really proposing anything concrete - just trying to work out how we collectively feel on this topic. My 2 cents is that once it's up on CPAN, it should at least be indexed if not fully indexed and stored like everything currently is. Give the outside developers enough information to find modules to suit their needs, but without any obvious obligation to find the best module to suit their needs, since that could be considered presumptuous. Christopher Josephes [EMAIL PROTECTED]
Re: James Freeman's other modules
On Fri, 12 Jan 2007 14:54:28 +, Andy Armstrong [EMAIL PROTECTED] said: 2 actively used, abandoned [...] identify cat 2 modules with a view to flagging them as abandoned The DSLIP status code has an 'a' reserved for the 'S' to mean support level: abandoned It is even used by at least one module, I forgot which. CPAN.pm will warn you when you install an abandoned module. See the manpage of CPAN.pm for the whole DSLIP short notation. -- andreas
