Re: what to do with dead camels ?
At 08:06 +0300 8/3/03, Gabor Szabo wrote: There are a few modules on CPAN that seem to be dead. Without pointing fingers (to myself :-), let's say there is a module called Dead::Camel someone started to develop, uploaded to CPAN but it never reached any form of usable version or for some other reason it is unusable today. Eliminating these modules from CPAN might do a little good for the world. I would be totally for moving these modules from CPAN and only have them be available on BackPAN. I have a few of them myself... Liz
Re: what to do with dead camels ?
On Sun, Aug 03, 2003 at 11:28:57AM +0200, Elizabeth Mattijsen wrote: > At 08:06 +0300 8/3/03, Gabor Szabo wrote: > >There are a few modules on CPAN that seem to be dead. > >Without pointing fingers (to myself :-), let's say there is a > >module called Dead::Camel someone started to develop, uploaded to > >CPAN but it never reached any form of usable version or for some > >other reason it is unusable today. > > > >Eliminating these modules from CPAN might do a little good for the > >world. > > I would be totally for moving these modules from CPAN and only have > them be available on BackPAN. I have a few of them myself... I think you can find someone to care about almost any CPAN module. Likewise, I suspect that all but the most redundant, and perhaps uselessly broken modules have at least one user who will be upset when it goes away. For those reasons, it might be better to offer dead camels to whoever wants to maintain them. If nobody steps forward after a time, then consider retiring them. At the very least, you can say: "Don't complain! You had your chance!" when they send you hate mail for breaking their programs. :) -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: what to do with dead camels ?
I wouldn't mind there being something in PAUSE that says "you have to touch the module once a year." I don't mean worthless updates, like MJD was talking about in one of his lightning talks, but at least that you have an interest in maintaining it. There's a distro on CPAN now called lcwa that I would love to see disappear. It's from 1997 and it's one of those distros that included all its necessary parts rather than rely on depencies. Unfortunately, those parts are 6 years out of date, but come up in searches on the modules. Do a search on search.cpan.org for "HTTP::Response", a pretty common module. The first hit that comes up is the one from lcwa, and if you're not paying attention to the distro name (or you're a relative newbie who doesn't realize he needs to), you're going to be looking at 6-year-old docs for the module. It turns out that in June there were 4000+ hits on modules in the lcwa distro instead of their "real" distros. That skews my stats for the Phalanx project, but more importantly, it means that 4000 times users got old docs. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: what to do with dead camels ?
On Sun, Aug 03, 2003 at 11:45:01AM -0500, Andy Lester wrote: > > It turns out that in June there were 4000+ hits on modules in the Glad you mentioned that, because I've been wondering, where can one find hit and download stats for CPAN modules? > lcwa distro instead of their "real" distros. That skews my stats for > the Phalanx project, but more importantly, it means that 4000 times > users got old docs. > Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance -Tim ** | Tim Maher (206) 781-UNIX (866) DOC-PERL (866) DOC-UNIX | | tim(AT)Consultix-Inc.Com TeachMeUnix.Com TeachMePerl.Com | *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-* | Watch for my Book: "Minimal Perl for Shell Programmers" | **
Re: what to do with dead camels ?
At 10:05 AM -0700 8/3/03, Tim Maher wrote: On Sun, Aug 03, 2003 at 11:45:01AM -0500, Andy Lester wrote: It turns out that in June there were 4000+ hits on modules in the Glad you mentioned that, because I've been wondering, where can one find hit and download stats for CPAN modules? You can't. I did a one-time munging of the access logs. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
RE: what to do with dead camels ?
> I wouldn't mind there being something in PAUSE that says "you have to > touch the module once a year." I don't mean worthless updates, like but how do you distinguish cases when module does not need updates, just because it does not needs to be updated (still in a good shape)? one-year cycle is not long enough. Vadim.
Re: what to do with dead camels ?
* Gabor Szabo ([EMAIL PROTECTED]) [03 Aug 2003 18:31]: [...] > If I encounter such a module what should I suggest to the author ? Ask the author to update or delete. Or offer to take over maintenance. Your problems begin when you can't *find* the author. Some of the older dists that bundle in other modules would benefit from having META.yml files with the private keyword (which needs some docs). cheers, -- Iain.
Re: what to do with dead camels ?
"Iain 'Spoon' Truskett" <[EMAIL PROTECTED]> writes: > Ask the author to update or delete. Or offer to take over maintenance. > Your problems begin when you can't *find* the author. Maybe a periodic 'ping' to module maintainers (e.g., once every two or three months) and mark maintainers (and their modules) that miss a couple of pings. Modules marked as such could be returned last by the search engines, and be clearly marked as being of 'undetermined' status. -- Johan
Re: what to do with dead camels ?
On Mon, 4 Aug 2003, Johan Vromans wrote: > Maybe a periodic 'ping' to module maintainers (e.g., once every two or > three months) and mark maintainers (and their modules) that miss a > couple of pings. Modules marked as such could be returned last by the > search engines, and be clearly marked as being of 'undetermined' status. That'd be awesome. -- The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
Re: what to do with dead camels ?
On Sun, 3 Aug 2003, Rocco Caputo wrote: > I think you can find someone to care about almost any CPAN module. > Likewise, I suspect that all but the most redundant, and perhaps > uselessly broken modules have at least one user who will be upset when > it goes away. I mainly meant those broken modules that cannot be installed either because the world evolved or because they were never reached that point. > > For those reasons, it might be better to offer dead camels to whoever > wants to maintain them. If nobody steps forward after a time, then > consider retiring them. > > At the very least, you can say: "Don't complain! You had your chance!" > when they send you hate mail for breaking their programs. :) I though of uploading an empty version with just an explanation that the module is obsolete but keeping the previous version for some time or pointing to backpan where one can find those old versions. Gabor
Re: what to do with dead camels ?
On Sunday 03 August 2003 17:45, Andy Lester wrote:
> There's a distro on CPAN now called lcwa that I would love to see
> disappear. It's from 1997 and it's one of those distros that
> included all its necessary parts rather than rely on depencies.
> Unfortunately, those parts are 6 years out of date, but come up in
> searches on the modules.
>
> Do a search on search.cpan.org for "HTTP::Response", a pretty common
> module. The first hit that comes up is the one from lcwa, and if
> you're not paying attention to the distro name (or you're a relative
> newbie who doesn't realize he needs to), you're going to be looking
> at 6-year-old docs for the module.
Try Test::More, it's true home is Test::Simple but that's 5th on the list.
Can I suggest a change to the sorting algorithm for search.cpan.org when
searching for a module or for docs
@sorted_distros = sort {
$a->oldest_version->release_date <=>
$b->oldest_version->release_date
} all_distros_containing("Module::Name");
Because chances are that if Distro::A includes a piece of Distro::B then
Distro::B probably predates Distro::A. Of course that's not necessarily true,
it's quite possible but that should be comparitively rare.
I think it doesn't fully solve the problem for Test::More but it might for
some others
F
RE: what to do with dead camels ?
> It turns out that in June there were 4000+ hits on modules in the could you please teach me how do you look such statistic? Is it available for public? TIA, Vadim.
Re: what to do with dead camels ?
> It turns out that in June there were 4000+ hits on modules in the could you please teach me how do you look such statistic? Is it available for public? Andy, why don't you talk with acme about getting such information added to the CPANTS metrics... clearly it is something that authors want to know. -- Sam Vilain, [EMAIL PROTECTED] The rich will do anything for the poor but get off their backs. KARL MARX
RE: what to do with dead camels ?
At 10:34 AM +0400 8/4/03, Konovalov, Vadim wrote: > I wouldn't mind there being something in PAUSE that says "you have to touch the module once a year." I don't mean worthless updates, like but how do you distinguish cases when module does not need updates, just because it does not needs to be updated (still in a good shape)? one-year cycle is not long enough. There would be something in PAUSE that would allow the author to say "I'm still here". The module itself need not change. It would be like the UNIX touch command. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: what to do with dead camels ?
Andy, why don't you talk with acme about getting such information added to the CPANTS metrics... clearly it is something that authors want to know. Oh, I have. It was talking with Leon that this project first came into being. My goal isn't to have an ongoing stats collection process like he's got, but a one-time list capture. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: what to do with dead camels ?
Try Test::More, it's true home is Test::Simple but that's 5th on the list. Understood. HTTP::Response was just an example, and one that was annoying me because of the skewing of the stats I was collecting... -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
RE: what to do with dead camels ?
At 08:58 -0500 8/4/03, Andy Lester wrote: At 10:34 AM +0400 8/4/03, Konovalov, Vadim wrote: > I wouldn't mind there being something in PAUSE that says "you have to touch the module once a year." I don't mean worthless updates, like but how do you distinguish cases when module does not need updates, just because it does not needs to be updated (still in a good shape)? one-year cycle is not long enough. There would be something in PAUSE that would allow the author to say "I'm still here". The module itself need not change. This could be as simple as sending an email once a month to the CPAN id's mail address and set a flag when it has bounced. Maybe once a year you would like the author to actually reply to make sure the mail isn't going into some bitbucket. Maybe something that Siesta can do as soon as it knows how to VERP... ;-) Liz
Re: what to do with dead camels ?
On Mon, Aug 04, 2003 at 10:24:29PM +0200, Elizabeth Mattijsen wrote: > This could be as simple as sending an email once a month to the CPAN > id's mail address and set a flag when it has bounced. Maybe once a > year you would like the author to actually reply to make sure the > mail isn't going into some bitbucket. > > Maybe something that Siesta can do as soon as it knows how to VERP... ;-) Yes, but... How much do you hate mailman for all those "here is a reminder of your mailing list memberships" messages? Happy mailman day? Or curse mailman day? I can see this as a really good way to piss people off. Anyway, it's moot point as you already know that the person assigned to VERP takes an awfully long time to getting a round tuit, so it's unlikely to be finished soon ( http://siesta.unixbeard.net/svn/trunk/siesta/TODO ) Nicholas Clark
Re: what to do with dead camels ?
At 21:58 +0100 8/4/03, Nicholas Clark wrote: Anyway, it's moot point as you already know that the person assigned to VERP takes an awfully long time to getting a round tuit, so it's unlikely to be finished soon ( http://siesta.unixbeard.net/svn/trunk/siesta/TODO ) Hmmm... that says: === =head2 Revisit bounce handling (VERP stuff) Nicholas Clark wants to look at this === ;-) Liz
Re: what to do with dead camels ?
On Tue, Aug 05, 2003 at 11:17:36AM +0100, Nicholas Clark wrote: > On Tue, Aug 05, 2003 at 01:27:47AM -0400, Christopher Hicks wrote: > > Maybe the e-mail should do something informative like list how many years, > > months and days it's been since a given module has been updated. Some > > weak souls might be guilted into pushing out bug fixes sooner. > > If there are no bugs, there is no need for bug fixes. > MJD gets very irritated with people asking whether certain of his > modules are abandoned, simply because the most recent version is old. The "Mature" development status (http://search.cpan.org/dlsip) is meant to address this. But it's not well integrated on search.cpan.org, in the sense that viewing a distribution page (http://search.cpan.org/author/MJD/Tie-File) doesn't show the DLSIP flags for the modules it contains. Tim.
Re: what to do with dead camels ?
At 11:17 +0100 8/5/03, Nicholas Clark wrote: But *do not* send out an "all's well" message, which will get filtered with the spam to /dev/null, because crying wolf like this will cause people to miss subsequent real, serious, messages. The message would e.g. consist of: - last time you accessed PAUSE (to make sure no one else is using your login) - related news that might be of interest as an author, e.g. $^V versus $] - open RT tickets (if any) So, if there is no news and no RT tickets, the message would at least contain the last access time. Which is a nice service, because then you _can_ be sure no one's messing with your login, without having to login yourself. Liz
Re: what to do with dead camels ?
On Mon, Aug 04, 2003 at 11:43:40AM +0100, Sam Vilain wrote: >> It turns out that in June there were 4000+ hits on modules in > > Andy, why don't you talk with acme about getting such information > added to the CPANTS metrics... clearly it is something that authors > want to know. If it matters, CPAN gives (or cites, really) good reasons why those statistics shouldn't be provided. FAQ: Does CPAN provide download statistics for authors? No we don't. http://xxx.lanl.gov/help/faq/statfaq sums up our thoughts on the matter quite well. -- Steve
Re: what to do with dead camels ?
Nicholas Clark sent the following bits through the ether: > But *do not* send out an "all's well" message Hear, hear! This thread has been very amusing but not very productive. Please produce a list of modules which you think are out of date and need to be taken over. Then please provide people willing to take them over. Sending emails is all very well but won't magically improve the quality of CPAN. Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... How do you pronounce my name? With reverence ;-)
Re: what to do with dead camels ?
On Tue, Aug 05, 2003 at 10:01:11AM -0500, Mark Stosberg wrote: > > The "Mature" development status (http://search.cpan.org/dlsip) is > > meant to address this. > > > > But it's not well integrated on search.cpan.org, in the sense that > > viewing a distribution page (http://search.cpan.org/author/MJD/Tie-File) > > doesn't show the DLSIP flags for the modules it contains. > > That information /is/ integrated into kobsearch.cpan.org, though: > http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?modinfo=18026 Thanks. Tim.
Re: what to do with dead camels ?
On Sun, Aug 03, 2003 at 10:05:46AM -0700, Tim Maher wrote: > > Glad you mentioned that, because I've been wondering, > where can one find hit and download stats for CPAN modules? Well, you can't :) There are over 200 mirrors, each running either ftp, http or both and we don't collect the logs. It's such a common question it's even on the FAQ that noone ever reads :) http://www.cpan.org/misc/cpan-faq.html#Plans_for_statistics I think Randy has a page of something but I can't seem to find the URL. I also used to run analog on the search logs but, again, I doubt that they would be accurate in any way for measuring module downloads and interest. e.
Re: what to do with dead camels ?
How about adding a "nextofkin" attribute to META.yml, say? The value of the nextofkin attribute might be a list of CPAN IDs and/or email addresses of people who have agreed to inherit your module should you die or become inactive. Ideally, at least one of the nextofkin should physically know the module owner, so that, in the event of bouncing emails, an email to the nextofkin will establish what has truly happened to the inactive module author. Not as much fun as "I think not" Descartes jokes, admittedly ;-) http://nntp.x.perl.org/group/perl.module-authors/927 /-\ http://personals.yahoo.com.au - Yahoo! Personals - New people, new possibilities! Try Yahoo! Personals, FREE for a limited period!
Re: what to do with dead camels ?
On Tuesday Andrew Savige wrote: > How about adding a "nextofkin" attribute to META.yml, say? That sounds like a great idea -- there doesn't seem to be any disadvantage in encouraging module authors to provide this information. (Of course it's of no use in tracing existing awol authors. And moving on it's likely that the people diligent enough to use it are also those careful enough to keep their e-mail addresses up to date ... but it's worth trying.) Smylers
Re: what to do with dead camels ?
On Tue, Aug 05, 2003 at 12:38:29AM -0400, Steve Grazzini wrote: > If it matters, CPAN gives (or cites, really) good reasons why > those statistics shouldn't be provided. > > FAQ: > > Does CPAN provide download statistics for authors? > > No we don't. http://xxx.lanl.gov/help/faq/statfaq sums up our > thoughts on the matter quite well. from xxx.lanl.gov: > It could be argued perhaps correctly that statistics may provide some useful > information at least on the relative popularity of submissions, since the > distributed access and other factors may be subsumable into some overall scale > factor. But even this information is ambiguous in many cases, and publicizing, > even when accurate, could merely accentuate faddishness in fields already > excessively faddish. Ambiguous, but I think CPAN stats could be potentially useful. Just as Schwern's Kwalitee is an approximation of quality, and does not aspire to providing "perfect" indicators of quality, a metric on CPAN useage could provide some sort of picture of the Perl community at large, as long as they include the caveats. Perhaps we need some Statisticks instead of Statistics :) > Most significantly, however, there is a strong philosophic reason for not > publicizing (or even saving) these statistics. When one browses in a library > it is very important (in fact legislated) that big brother is not watching > through a camera mounted on the wall; for the benefit of readers it is very > important to maintain in every way possible this sense of freedom from > monitoring in the electronic realm. This also is true, however legislation prevents making an *individuals* browsing patterns public. Any good library closely monitors it's circulation statistics and looks for patterns to guide future collection development. So if titles in an area such as Camel Biology are continuously checked out by a diverse group of people, the Library can decide to better serve its community by purchasing more books in this area. //Ed
Re: what to do with dead camels ?
On Mon, Aug 04, 2003 at 10:24:29PM +0200, Elizabeth Mattijsen ([EMAIL PROTECTED]) wrote: > This could be as simple as sending an email once a month to the CPAN > id's mail address and set a flag when it has bounced. Maybe once a > year you would like the author to actually reply to make sure the > mail isn't going into some bitbucket. But that doesn't mean that the module hasn't been abandoned by the author... -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: what to do with dead camels ?
elaine wrote: I also used to run analog on the search logs but, again, I doubt that they would be accurate in any way for measuring module downloads and interest. They're not, as I can readily attest. According to those stats, CSS::SAC is one *really* popular module. Ego boost apart, I know there are people using that module but certainly far from enough to make it compete stat-wise with the likes of LWP or DBI (which at some point it did in the stats). The reason for that fake popularity is that it is linked from the main page of the CSS section on the W3C website. That site is in the top of Google's karma list, probably very high in other places, and anyway constantly being indexed (and its links with it) by hundreds of bots -- and the odd lost user clicking on a random link. I think CPANPLUS had something to track installed modules stats, don't where it's at right now. It's certainly a far better measure. -- robin
Re: what to do with dead camels ?
On Wed, Aug 06, 2003 at 09:43:13AM -0500, Mark Stosberg wrote: > > I don't mind that there are a lot of rarely modules that are still > accessible. I mind when they show up in search results and I have to > wade through them to get to the juicy modules. There is not an easy way > to distinguish the signal from the noise on CPAN. That's what the > CPANTS [1] proposal was targeted to address. > > http://search.cpan.org/perldoc?Module::CPANTS I'm aware of CPANTS :) I bought Leon on auction to get him to work more on CPANTS. Thomas Klausner also has been working with CPANTS and you may find http://domm.zsi.at/cpants/search of some interest. > At least a couple of us are: > http://rt.cpan.org/NoAuth/Bug.html?id=2978 > > I think it's a stale joke that's wasting new resources daily. Well, it was presumeably for an article to show kids how to upload Acme modules automatically so I'm sure there will be more to come along with the final exercise at the end of the CPAN chapter in LPORM which instructs the aspiring student to upload their homework from previous chapters onto CPAN. e.
Re: what to do with dead camels ?
On Thu, Aug 07, 2003 at 04:51:15AM -0400, Christopher Hicks wrote: > Sorry for beating the dead horse a little more, but here goes... > > On Tue, 5 Aug 2003, Nicholas Clark wrote: > > But *do not* send out an "all's well" message, which will get filtered > > with the spam to /dev/null, because crying wolf like this will cause > > people to miss subsequent real, serious, messages. > > Sheesh. It's not crying wolf. It's saying "here's the status of your > stuff". When you get a monthly statement from your bank they're not > crying wolf. They're keeping you up to date. My accountant is hopefully > more on top of things than the bank so the only purpose in the statement > is to make sure the bank hasn't screwed up, but I don't accuse them of > crying wolf because they want to keep me appraised of things. Have you heard? Generalissimo Francisco Franco is still dead. See http://www.wikipedia.org/wiki/Generalissimo_Francisco_Franco_is_still_dead for the latest news. Periodic e-mail messages don't do anything to stop bit rot on the CPAN. They just let us shave it off and sweep it under the carpet. That seems counterproductive, especially since the correlation between having an inbox and maintaining a distribution isn't proven. On the other hand, the CPAN testers help authors maintain good code, and they help consumers find good modules. They do the former by sending failure notices to authors when new uploads are broken. They do the latter by providing reports that consumers can use to evaluate distributions. They don't prevent bit rot in stuff already on the CPAN, however. I think they could, but it would require them to retest dependent modules whenever a dependency passed its tests. The failure notices would alert authors that their distributions are succumbing to bit rot. Theoretically, they would care about their code and update it in relatively short order. Likewise it might be useful to send an automated message to the dependency's author: Your upload, FooBar-12.99, has caused new test failures in the following distribution(s): Deadbeats wouldn't bother, and they'd receive correspondingly more notifications. "Goofus doesn't update his CPAN distributions and gets a lot of e-mail about his broken code. Gallant keeps his code up to date, and lives in relatively unaccosted bliss." Which brings us back to e-mail validation. Since the testers are sending out all these notices, perhaps they could monitor and report on bounces. Other systems, like PAUSE, could use the information to prompt authors to fix their e-mail addresses when they log in. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: what to do with dead camels ?
On Tue, Aug 05, 2003 at 09:47:09AM -0500, Ken Williams wrote: > > I agree. There are plenty of modules on CPAN that people still find > useful even though they haven't had recent development on them. It's > much better to inform people of known/serious bugs in modules, than to > try to guess at the author's intentions WRT the module. I think MJD expressed this best at YAPC when he became very animated in one of his '12 views' LT, ranting about how someone accused him of neglecting his Text::Template module when, as he said, it was mature, perfect. He blames this update mentality on Microsoft. > I believe our challenge is not to enforce some kind of standards on > CPAN, but to make sure that people can efficiently find the most > appropriate tools for their needs. I think the search.cpan.org > redesign was really a *huge* leap forward for that, and I'd like to see > similar efforts continue in that direction. Well, you know, CPAN and BackPAN /are/ archives...there are a lot of crap books in every library that noone reads much but will occasionally get sent out on loan :) They don't eat much space and, aside from ones parked on a good namespace with clear neglect, they're mostly not worth the stress of getting fussy over. On the other end of the spectrum is Acme::Current which noone seems to be making noise about. It is a commons...choose your battles wisely or you'll be mired in battle for a long time to come. e.
Re: what to do with dead camels ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * elaine [2003-08-06 08:22]: > On Sun, Aug 03, 2003 at 10:05:46AM -0700, Tim Maher wrote: > > > > Glad you mentioned that, because I've been wondering, where can one > > find hit and download stats for CPAN modules? > > Well, you can't :) There are over 200 mirrors, each running either > ftp, http or both and we don't collect the logs. It's such a common > question it's even on the FAQ that noone ever reads :) That's not to mention the private mirrors, of course, and copies generated from those mirrors. (darren) - -- I don't mow lawns for the reason that I don't shave. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: This message is digitally signed and can be verified for authenticity. iD8DBQE/MQJlzsinjrVhZaoRAhGLAJ0SDpOGw3iAdqyhjZ77stgPLvk3BwCfcLey QHEiuYQZr8emEhK3EBLc3gk= =Av76 -END PGP SIGNATURE-
Re: what to do with dead camels ?
On Wed, Aug 06, 2003 at 04:15:25AM -0500, elaine wrote: > > Well, you know, CPAN and BackPAN /are/ archives...there are a lot of > crap books in every library that noone reads much but will occasionally > get sent out on loan :) They don't eat much space and, aside from ones > parked on a good namespace with clear neglect, they're mostly not worth > the stress of getting fussy over. I don't mind that there are a lot of rarely modules that are still accessible. I mind when they show up in search results and I have to wade through them to get to the juicy modules. There is not an easy way to distinguish the signal from the noise on CPAN. That's what the CPANTS [1] proposal was targeted to address. http://search.cpan.org/perldoc?Module::CPANTS > On the other end of the spectrum is > Acme::Current which noone seems to be making noise about. At least a couple of us are: http://rt.cpan.org/NoAuth/Bug.html?id=2978 I think it's a stale joke that's wasting new resources daily. Mark
Re: what to do with dead camels ?
On Tue, Aug 05, 2003 at 01:27:47AM -0400, Christopher Hicks wrote: > Maybe the e-mail should do something informative like list how many years, > months and days it's been since a given module has been updated. Some > weak souls might be guilted into pushing out bug fixes sooner. If there are no bugs, there is no need for bug fixes. MJD gets very irritated with people asking whether certain of his modules are abandoned, simply because the most recent version is old. Why are you assuming that all stable code has known but unfixed bugs? If anything, have rt.perl.org send out ping messages about new (but unresponded to) bugs, or maybe open but serious bugs, because these do have content But *do not* send out an "all's well" message, which will get filtered with the spam to /dev/null, because crying wolf like this will cause people to miss subsequent real, serious, messages. Nicholas Clark
Re: what to do with dead camels ?
> The "Mature" development status (http://search.cpan.org/dlsip) is > meant to address this. > > But it's not well integrated on search.cpan.org, in the sense that > viewing a distribution page (http://search.cpan.org/author/MJD/Tie-File) > doesn't show the DLSIP flags for the modules it contains. That information /is/ integrated into kobsearch.cpan.org, though: http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?modinfo=18026 Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: what to do with dead camels ?
On Tuesday, August 5, 2003, at 05:17 AM, Nicholas Clark wrote: If there are no bugs, there is no need for bug fixes. MJD gets very irritated with people asking whether certain of his modules are abandoned, simply because the most recent version is old. Why are you assuming that all stable code has known but unfixed bugs? If anything, have rt.perl.org send out ping messages about new (but unresponded to) bugs, or maybe open but serious bugs, because these do have content I agree. There are plenty of modules on CPAN that people still find useful even though they haven't had recent development on them. It's much better to inform people of known/serious bugs in modules, than to try to guess at the author's intentions WRT the module. Give people the real information, and they will be able to make their own judgments about a module's fitness for their purpose. I've gotten emails out of the blue about some of my modules I'd assumed were long ago forgotten, but apparently they scratched some unexpected itch for somebody at the right time. I believe our challenge is not to enforce some kind of standards on CPAN, but to make sure that people can efficiently find the most appropriate tools for their needs. I think the search.cpan.org redesign was really a *huge* leap forward for that, and I'd like to see similar efforts continue in that direction. -Ken
Re: what to do with dead camels ?
On Wed, Aug 06, 2003 at 09:28:05AM -0400, darren chamberlain wrote: > > That's not to mention the private mirrors, of course, and copies > generated from those mirrors. Or CD distributions of CPAN or OS distributions of modules...etc. Yes. :) e.
Re: what to do with dead camels ?
elaine writes: > On Wed, Aug 06, 2003 at 09:43:13AM -0500, Mark Stosberg wrote: > > > I think [Acme::Current]'s a stale joke that's wasting new resources > > daily. > > Well, it was presumeably for an article to show kids how to upload > Acme modules automatically ... Oh, I'd been presuming it was Googlebot fodder. Every release ends up at a brand new URL, and the docs for the module (in the 'See Also' section) contain a plug for the author's business, with a hyperlink. So the regular uploads ensure a steadily increasing number of pages linking to that page, thereby increasing its pagerank. Smylers
Re: what to do with dead camels ?
Sorry for beating the dead horse a little more, but here goes... On Tue, 5 Aug 2003, Nicholas Clark wrote: > On Tue, Aug 05, 2003 at 01:27:47AM -0400, Christopher Hicks wrote: > > Maybe the e-mail should do something informative like list how many years, > > months and days it's been since a given module has been updated. Some > > weak souls might be guilted into pushing out bug fixes sooner. > > If there are no bugs, there is no need for bug fixes. Agreed. > MJD gets very irritated with people asking whether certain of his > modules are abandoned, simply because the most recent version is old. If all module writers wrote like MJD there'd be no need for this disussion or this list. :) > Why are you assuming that all stable code has known but unfixed bugs? I'm not. But I've dealt with a variety of different CPAN modules that were avaiable as updated from the authors site that took ages (as in a few years IIRC) to make it to CPAN. How many months of watching this sort of thing go on is considered acceptable before taking the module and uploading it myself? > If anything, have rt.perl.org send out ping messages about new (but > unresponded to) bugs, or maybe open but serious bugs, because these do > have content That's be nice to include and maybe the message could be sent more often to those with unassigned bugs in their modules. > But *do not* send out an "all's well" message, which will get filtered > with the spam to /dev/null, because crying wolf like this will cause > people to miss subsequent real, serious, messages. Sheesh. It's not crying wolf. It's saying "here's the status of your stuff". When you get a monthly statement from your bank they're not crying wolf. They're keeping you up to date. My accountant is hopefully more on top of things than the bank so the only purpose in the statement is to make sure the bank hasn't screwed up, but I don't accuse them of crying wolf because they want to keep me appraised of things. If people are this morally opposed to receiving an e-mail every few months maybe the implementor of this idea should let folks "bury their head in the sand" and stay happy. And presumably this would come from some fixed address used for solely this purpose, so who's really going to miss e-mail over this? -- The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
Re: what to do with dead camels ?
Christopher Hicks <[EMAIL PROTECTED]> writes: > On Mon, 4 Aug 2003, Nicholas Clark wrote: > > > How much do you hate mailman for all those "here is a reminder of your > > mailing list memberships" messages? > > They're only slightly irritating and I get a dozen of them every month. > If they wouldn't show up on lists that I'd actually been active on I'd > probably read some lists more often. For me, these mails are automatically stored in a local GNUs group. I keep them. I only visit this group when there are new messages (all handled automatically by GNUs). Since message threading is enabled, I can see immediately if there are new messages, or just repeats of messages I already have. A single keystroke purges the duplicates. In short, 'happy mailman day' costs me only three keystrokes. -- Johan
Re: what to do with dead camels ?
Nicholas Clark <[EMAIL PROTECTED]> writes: > Yes, but... > > How much do you hate mailman for all those "here is a reminder of your > mailing list memberships" messages? That's why my initial suggestion was once per three months... -- Johan
Re: what to do with dead camels ?
On Mon, 4 Aug 2003, Nicholas Clark wrote: > How much do you hate mailman for all those "here is a reminder of your > mailing list memberships" messages? They're only slightly irritating and I get a dozen of them every month. If they wouldn't show up on lists that I'd actually been active on I'd probably read some lists more often. > Happy mailman day? Or curse mailman day? Whatever mailman day. After deleting six thousand spam per month, deleting a dozen mailman messages is going to hurt you? > I can see this as a really good way to piss people off. It's possible to use it to piss people off, but people can procmail it or do other things and if it were done right it would help weed out dead wood on CPAN and that's helpful. As I understand it this wouldn't affect module authors who have updated versions or clicked somewhere saying "I haven't whithered away at my desk yet". And it wouldn't have to be sent out except maybe every quarter (or longer for people that didn't respond to the previous ping). It doesn't seem that would generate much flack. Maybe the e-mail should do something informative like list how many years, months and days it's been since a given module has been updated. Some weak souls might be guilted into pushing out bug fixes sooner. -- The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
Re: what to do with dead camels ? work on CPANTS
Hello, As long as we are discussing ways to improve the quality of CPAN, this seems like a good time to mention CPANTS. While addresses Dead Camels does patch a hole in CPAN, Schwern's CPANTS proposal provides a complete solution for quality control for CPAN. Here's a link to more information about it: http://use.perl.org/~markjugg/journal/13121 This project is already underway and in its early stages in the form of "Module::CPANTS". Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
