Re: Future of the Module List
So, if I want to write a review of Net::SMTP, I'd do the following. 1. Use Module::Build, or ExtUtils::MakeMaker to create Review::Net::SMTP::CHRISJ, or whatever. 2. Make sure I have my README.txt, CHANGES, and MANIFEST file. 3. Write my review in POD format, and throw in some META.yml indexing code as well. 4. Make sure the module/review is executable so it passes CPAN testing. 5. Upload the review to CPAN. On Tue, 20 Jul 2004, Sam Vilain wrote: I nominate the Review::* Namespace for author-submitted module indexes and in-depth reviews, in POD format. I think this has a number of advantages. Let's use the infrastructure we already have, no? The .pm versions of these modules could potentially contain lists (in YAML format of course) for use by the indexing systems, which would, after double checking, be used as a master data source for the auto-generated indexes and modules lists. This probably needs to be prototyped a little, and a model review module (say that 5 times quickly) posted before reviews start coming in in earnest. Sam. Christopher Josephes [EMAIL PROTECTED]
Re: Future of the Module List
On Jul 20, 2004, at 11:57 AM, Chris Josephes wrote: So, if I want to write a review of Net::SMTP, I'd do the following. 1. Use Module::Build, or ExtUtils::MakeMaker to create Review::Net::SMTP::CHRISJ, or whatever. 2. Make sure I have my README.txt, CHANGES, and MANIFEST file. 3. Write my review in POD format, and throw in some META.yml indexing code as well. 4. Make sure the module/review is executable so it passes CPAN testing. 5. Upload the review to CPAN. I was sort of hoping this idea would just die on its own, but now it looks like people are actually getting ready to do it. In my opinion this is a bad idea. I don't want a bunch of reviews all over CPAN disguising themselves as modules. I also don't want CPAN sites to have to figure out what's a review and what's not, so they can filter out the reviews. What's wrong with making one of these newfangled things called web sites to host reviews? Oh, I know - that already exists. So how about working with those people to fix whatever you think is broken about them before polluting CPAN with all this non-code? -Ken
Re: Future of the Module List
On Thu, 22 Jul 2004 13:50:37 -0500, Ken Williams [EMAIL PROTECTED] wrote: I was sort of hoping this idea would just die on its own, but now it looks like people are actually getting ready to do it. In my opinion this is a bad idea. I don't want a bunch of reviews all over CPAN disguising themselves as modules. I also don't want CPAN sites to have to figure out what's a review and what's not, so they can filter out the reviews. I too was hoping this would die on its own as an Obviously Bad Idea. Having a bunch of POD-only modules is about as appropriate as a review medium as using email signatures. Please, don't do this. Make the CPAN ratings web site better, or start your own web site, and use a storage medium other than the CPAN module repository. -John
Re: Future of the Module List
On Thu, 22 Jul 2004, Ken Williams wrote: I was sort of hoping this idea would just die on its own, but now it looks like people are actually getting ready to do it. In my opinion this is a bad idea. I don't want a bunch of reviews all over CPAN disguising themselves as modules. I also don't want CPAN sites to have to figure out what's a review and what's not, so they can filter out the reviews. Agreed. I kind of hoped that by pointing out the steps that would be involved in posting a review, people would kind of get the clue that the proposal needs a little work. What's wrong with making one of these newfangled things called web sites to host reviews? Oh, I know - that already exists. So how about working with those people to fix whatever you think is broken about them before polluting CPAN with all this non-code? It would be really easy to set up a blog or whatever to handle this, but inevitably someone always asks the question What About CPAN? I'm probably not on enough Perl mailing lists to make an expert opinion, but the impression I get is that CPAN is a system without a clearly defined future. Questions always come up on who maintains it, where is the code, how do we add this feature, why is the module list out of date, etc, etc. CPAN works great for distributing perl code and modules, but as a software package, CPAN is a mystery to a lot of us. -Ken Christopher Josephes [EMAIL PROTECTED]
The CPAN Guide [was Re: Future of the Module List]
Mark Stosberg wrote: Maybe the convention could be: Review::Text::Balanced::CPANUSERNAME Good idea, but I think that is duplicated information. CPAN already considers the uploaded user ID to be a part of the unique name of the module. Two authors can upload a module with the same name; and that is fine; they will both be displayed uniquely when found on search.cpan.org. Of course, when installing via CPAN.pm, the indexer will only automatically choose the versions of the modules written by the current maintainer (or some rule like that). For reviews, this is not really a major consideration - except maybe for people compiling CPAN discset compilations. OTOH, a link to http://search.cpan.org/dist/Some-Dist/ will go to whichever has the highest version number (see http://search.cpan.org/dist/Data-Lazy/ for an example). Perfect. Rather than trying to double the size of CPAN by making a review for each module, a review could cover a wide variety of different modules that cover a related problem space. The reviews could be supplemented with examples and demonstrations exhibiting strengths and weaknesses of the modules that they review - for instance, benchmarking, memory tests, etc. As new modules are written, the reviews could be extended (perhaps, but not necessarily by the same author as the original review). You will get a similar situation to many of the modules in CPAN today, which have more than a handful of maintainers who have contributed. There's nothing to say that individual module reviews shouldn't be written, and the convention of naming the review module the same as the single module it covers with a prefix is a good one. This would almost certainly be linked to by the module which covers the generic problem space. So, to make this distinction clear, maybe the Guide::* namespace should cover problem space reviews, and serve as something of another index to CPAN - and Review::* can be for more in-depth reviews of individual CPAN modules, to avoid potentional conflicts from using Review::* for both of these. Besides, I think Guide:: is more accurate here. If no-one has any sound objections or beats me to the task, I will endeavour to complete Guide.pod, and Guide/Example.pod during my recreational Perl development time (not as abundant at present as it once was ;-)), and construct a skeleton of Guide:: distributions based on the old modules list. But first, back to reinventing some more wheels ;-). -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: Future of the Module List
On Tue, Jul 20, 2004 at 06:15:49PM +1200, Sam Vilain wrote: I nominate the Review::* Namespace for author-submitted module indexes and in-depth reviews, in POD format. I think this has a number of advantages. Let's use the infrastructure we already have, no? Interesting, but what comes after Review:: if it's Review::Text::Balanced then how do we get multiple reviews Text::Balanced or are you talking about something else entirely? F
Re: Future of the Module List
On Tue, Jul 20, 2004 at 10:10:02AM +0100, Fergal Daly wrote: On Tue, Jul 20, 2004 at 06:15:49PM +1200, Sam Vilain wrote: I nominate the Review::* Namespace for author-submitted module indexes and in-depth reviews, in POD format. I think this has a number of advantages. Let's use the infrastructure we already have, no? Interesting, but what comes after Review:: if it's Review::Text::Balanced then how do we get multiple reviews Text::Balanced Maybe the convention could be: Review::Text::Balanced::CPANUSERNAME I'll let someone else suggest what should happen if the same person decides to review the same module multiple times. (Perhaps there would be an early negative review, and then a later positive review after the module improved with feedback.) Mark
Re: Future of the Module List
On Tue, Jul 20, 2004 at 03:57:10PM +0100, Fergal Daly wrote: The more I think about it, the more I think that it's not a great idea using the real CPAN to do things other than distribute code. Reuse the infrastructure by all means but the idea of mixing bundles, code, reviews and whatever else comes up in the same hierarchy with just naming conventions to tell them apart does not appeal to me. If we weren't dependent on collapsing all the relevant information down into a :: delimited list it would be much nicer (fantasy land, I know), I realize it's not a clean solution, but there are some things I like about it: - I can check http://search.cpan.org/recent for new modules and new module reviews. The means one less place to check for new and interesting Perl things that have been published. (OTOH, perhaps using an RSS News reader / aggregator would solve this just as well. ) - I like the idea of searching for a term and finding modules and reviews coming back. OTOH, we already have CPAN ratings for this. [ Thinks more. ]. OK, I'm changing my mind. I think it makes more sense to have a way to integrate longer reviews with cpanratings.perl.org. Perhaps a simple solution would be provide a field to link to longer review, which could be anywhere in any format. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Cpan Ratings (Was: Future of the Module List)
Pardon my ignorance, but ... What is the 'default phone-home behavior' in the Makefile.PL's about which Randal was complaining? Is it the author's 'Perlish' coding style, in which he places statement-ending semicolons at the start of the line? Or something else? jimk
Re: Cpan Ratings (Was: Future of the Module List)
James Keenan writes: Pardon my ignorance, but ... What is the 'default phone-home behavior' in the Makefile.PL's about which Randal was complaining? The author wished to keep track of how widely his modules were used -- at least partially as motivation for bothering to write them. Originally he had something in Makefile.PL which downloaded a file from his own website then executed the contents of that file. (Among other things, it warned the would-be-installer if a newer version of the distro was available.) People pointed out how insecure this is, and the damage that could be done by somebody hijacking his server and substituting a malicious Perl script at that URL. Others simply didn't like the idea at all of being counted and monitored without their consent; this phone-home behaviour happened by default, without warning. Somebody merely running Makefile.PL (or the CPAN shell or whatever) wouldn't expect it. The author responded to the security problem by changing his installers to download a dynamically generated data file, not a Perl script, which still allowed him to do counting and have the installer warn about old versions, but didn't have the security risk. But this still happened without warning, and would be unexpected to most users. Several people, Randal included, found this intrusive and unacceptable. I see that a few weeks ago the author removed all phone-home behaviour, so even this is no longer an issue. Smylers
Cpan Ratings (Was: Future of the Module List)
Randy W. Sims writes: Not long ago I was exploring the cpanratings site and discovered the unhelpful rampage by one particular reviewer http://cpanratings.perl.org/a/181. Why do you think Randal's comments are unhelpful? Personally whenever I'm (considering) downloading a module I haven't used before I read any reviews it has. It would never've occurred to me that an author would've have put default phone-home behaviour into a distribution's installer, but on reading Randal's review of a module I'd then be aware of it in advance. That's certainly useful information to have. Admittedly when you look at the page giving all Randal's reviews there is a fair amount of repetition going on, but the information he gives is pertinent to every one of those modules, so it's the only way of ensuring the message reaches potential users of all of the modules. Actually I'm much more concerned by the opposite problem, that people give 5 stars to modules they use lots and don't bother reviewing other modules, or ones they tried a bit but gave up on -- partly, I suspect, cos if you never quite got into a module properly then you feel it'd be unfair to review it. Look at one of the modules that Randal reviews, CGI::Builder: http://cpanratings.perl.org/d/CGI-Builder That's a flurry of 5-star reviews in a very short space of time. I suspect that isn't a co-incidence -- perhaps there's a CGI::Builder mailing list somewhere that had a recent post encouraging users to review the module? There isn't anything wrong with that[*0], but it could distort the value of reviews over all. Cpan Ratings is still young. Let's give it some more time to pan out; I think it's one of the better ideas out there. There's also some degree of a chicken-and-egg situation going on, but once the site has more reviews in it there'll be more reason for people to consult it and for places to link to it more prominently. [*0] Well, there are ways in which such a mail could be phrased that would be wrong; but simply soliciting genuine reviews from genuine users can hardly be faulted. Smylers
Future of the Module List
On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote: On Wed, 14 Jul 2004, A. Pagaltzis wrote: * Dave Rolsky [EMAIL PROTECTED] [2004-07-14 19:26]: Some of them _are_ registered, but that document you're referring to hasn't been regenerated since 2002/08/27! I wish the CPAN folks would just remove it if it won't be generated regularly. Does anyone else here think that the list should probably just be done away with entirely? The _file_ should go, yes. The concept of registering modules is different. Given the fact that most authors seem to not register their stuff, the [EMAIL PROTECTED] list is slow as heck, and that the web pages never get regenerated, yes. Those are all fixable. Volunteers? The real issues are bigger and deeper. I've appended a couple of emails. Tim. On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote: On Mon, 16 Feb 2004 01:32, Tim Bunce wrote; I'd like to see a summary of what those needs of the community are. (Maybe I missed it as I've not been following as closely as I'd have liked. In which case a link to an archived summary would be great.) It's very important to be clear about what the problems actually are. I don't really want to argue this side of things, I think that the problems pretty much speak for themselves. But I hate unspoken consensus, so let me suggest a few from my perspective; this applies to the combined Perl 5 modules list / using search.cpan.org: I'll play devils advocate here and point out some alternative remedies for the problems. By doing so I'm _not_ trying to detract for your suggestion, which I like, I'm just trying to show how existing mechanisms could be improved incrementally. a) searching for modules for a particular task takes a long time and unless you get your key words right, you might not find it at all. Refer the recent Mail::SendEasy thread. Calls for a richer set of categories and cross-links of some kind. (Editorial content alone is basically just more words to a search engine.) b) it is very difficult to find good reviews weighing the pros and cons of similar modules; they exist, but are scattered. CPAN ratings was a nice idea, but has too many First Post! style reviews to be useful in its current form IMHO. Argues for moderation of reviews and a minimum review length. A was this review helpful mechanism would also help to bring better reviews to the top. Also the search.cpan.org should not just show the overall rating, it should show the underlying three individual ratings (docs, interface, ease of use). c) it is nearly impossible to tell which modules are the wisest choices from a community size point of view; using modules that are more likely to fall out of maintenance is easy to do. Argues for more stats. I think useful *relative* download stats could be extracted from a sample of CPAN sites. Also search.cpan.org could provide relative page-*view* stats for modules. d) some great modules are not registered (I am referring of course to such masterpieces as Pixie, Heritable::Types, Maptastic :), Spiffy, Autodia, Want ... and those are just the ones missing in my bag of tricks) Argues for fixing the registration process. Originally the Module List had two goals: 1: to help people find perl modules for a particular task. 2: to provide a second-tier of modules above the 'anarchy' of people uploading half-baked ideas with half-baked names. Honourable goals, which it solved adequately for a period of time, and full credit where it is due. But now let's look at where we are. We've got masses of modules, truckloads of categories and thousands of contributors. This task cannot be left in the hands of a handful of hackers, no matter how much awe they inspire, they probably still have lives and day jobs ;) The registration process can, and should, be automatic for any modules for which no one objects. You'd apply and RT would automatically register if no one commented on the application. I will maintain that the current format, or even simply adding some more fields to the database is *not* enough information to give uninformed people looking for a module the information to make an informed decision. It is my gut feeling that only editorial content, managed by people who are experts in the field, will truly perform this task - and that to gain maximum support, that it should be included in the content mirrored along with the rest of cpan.org. I agree that comparative editorial reviews would be very valuable for Goal 1 above. I wouldn't address Goal 2 effecively at all. I think we're mature enough as a community to be able to produce this content without it disolving into flamewars or being too one-sided. In particular, I really think that as little red tape should be applied to this system as possible. Let's just set up a few
Re: Future of the Module List
On 7/14/2004 5:51 PM, Tim Bunce wrote: On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote: On Wed, 14 Jul 2004, A. Pagaltzis wrote: * Dave Rolsky [EMAIL PROTECTED] [2004-07-14 19:26]: Some of them _are_ registered, but that document you're referring to hasn't been regenerated since 2002/08/27! I wish the CPAN folks would just remove it if it won't be generated regularly. Does anyone else here think that the list should probably just be done away with entirely? The _file_ should go, yes. The concept of registering modules is different. Given the fact that most authors seem to not register their stuff, the [EMAIL PROTECTED] list is slow as heck, and that the web pages never get regenerated, yes. Those are all fixable. Volunteers? The real issues are bigger and deeper. I've appended a couple of emails. Tim. On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote: On Mon, 16 Feb 2004 01:32, Tim Bunce wrote; I'd like to see a summary of what those needs of the community are. (Maybe I missed it as I've not been following as closely as I'd have liked. In which case a link to an archived summary would be great.) It's very important to be clear about what the problems actually are. I don't really want to argue this side of things, I think that the problems pretty much speak for themselves. But I hate unspoken consensus, so let me suggest a few from my perspective; this applies to the combined Perl 5 modules list / using search.cpan.org: I'll play devils advocate here and point out some alternative remedies for the problems. By doing so I'm _not_ trying to detract for your suggestion, which I like, I'm just trying to show how existing mechanisms could be improved incrementally. a) searching for modules for a particular task takes a long time and unless you get your key words right, you might not find it at all. Refer the recent Mail::SendEasy thread. Calls for a richer set of categories and cross-links of some kind. (Editorial content alone is basically just more words to a search engine.) Are we talking about the same thing: perl.module-authors:2601 ? b) it is very difficult to find good reviews weighing the pros and cons of similar modules; they exist, but are scattered. CPAN ratings was a nice idea, but has too many First Post! style reviews to be useful in its current form IMHO. Argues for moderation of reviews and a minimum review length. A was this review helpful mechanism would also help to bring better reviews to the top. Also the search.cpan.org should not just show the overall rating, it should show the underlying three individual ratings (docs, interface, ease of use). This is definately a trouble area. Not long ago I was exploring the cpanratings site and discovered the unhelpful rampage by one particular reviewer http://cpanratings.perl.org/a/181. Maybe breaking the reviews into catagories would be helpful? Rate: installation, interface, robustness, overall, etc. c) it is nearly impossible to tell which modules are the wisest choices from a community size point of view; using modules that are more likely to fall out of maintenance is easy to do. Argues for more stats. I think useful *relative* download stats could be extracted from a sample of CPAN sites. Also search.cpan.org could provide relative page-*view* stats for modules. Narrow the interface for CPAN such that all viewing takes place on a single server where it can be monitored, and all download requests are distributed to mirror sites (ala sf.net). As for the best of the best, I still believe there is a lot of merrit in the list built from dependencies idea. d) some great modules are not registered (I am referring of course to such masterpieces as Pixie, Heritable::Types, Maptastic :), Spiffy, Autodia, Want ... and those are just the ones missing in my bag of tricks) Argues for fixing the registration process. This is why I am mailing you to ask: what's going on? Why is such an outdated module list being published in an authoritative location, and where can I get an up-to-date list? Module List *document* was maintained by hand. When managment of the Module List *data* was automated there was a desire to automate maintainance of the document but the document had a slightly richer structure than the data. That small hurdle meant automation never happened and the document was left unmaintained. Around the same time search.cpan.org became functional so the document had less relevance and busy people had other things to do. I'll happily conceed that the *document* isn't important these days. But I feel strongly that the *principle* (of moderated naming and categorization) is. The main pieces currently missing are: 1. Automated handling of module registration. [Where has that got to?] 2. Better integration of registration data into search.cpan.org So registration details are includes in search results, for example. 3. A 'fast path' process to
Re: Future of the Module List
On Wed, 14 Jul 2004, Randy W. Sims wrote: As for the best of the best, I still believe there is a lot of merrit in the list built from dependencies idea. Only in some areas. For example, the top templating modules are probably, TT, HTML::Template, Mason. How many modules depend on any of those? Darn few, because they are kind of at the end of the module food chain. OTOH, many modules in the DateTime suite depend on DateTime.pm. This doesn't make it best of breed (though I think it is for other reasons ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
