Front page | perl.module-authors |
Postings from April 2008
Re: Idea: CPAN Category Reviews
From: Guy Hulbert
April 5, 2008 07:35
Re: Idea: CPAN Category Reviews
Message ID: email@example.com
On Sat, 2008-05-04 at 16:54 +0300, Shlomi Fish wrote:
> On Saturday 05 April 2008, Guy Hulbert wrote:
> > On Sat, 2008-05-04 at 15:16 +0300, Shlomi Fish wrote:
> > > one
> > > paragraph summary then:
> > >
> > > <<<<<<<<<<<<
> > > I suggest having a feed of human readable (and possibly machine
> > > readable)
> > > reviews of the modules in various CPAN categories, as an indication of
> > > which
> > > modules are recommended and when and which are not.
> > already exists ( cpan-testers ? ).
> I don't see it existing.
Hence my question mark.
> > a) It is not sufficiently easy to find useful modules.
> > b) There are several ways to create modules.
> > c) Existing documentation is contradictory.
> I think a) is the most important problem which I'm trying to address. I'll
Ah. We agree on something ;-)
> I don't see b) as a problem. I'm using Module::Build and am happy with it.
I only see it as a problem since the maintainer (i said 'author' before,
which was wrong) of EU::MM says on his site that he's trying to
deprecate it but 'perldoc perlmodlib' says it is still official and does
not mention M::B, nor M::I, iirc.
> > I think (a) is the most important problem to solve.
> So do I.
Let me summarize (including my responses further below):
1. The problem to be solved is to make useful modules easier to find.
My solution (new modules):
2. A small change to the PAUSE upload interface adding some optional
fields which add appropriate meta-data to CPAN.
Your solution (existing modules - and lazy authors :-)
3. Voluntary reviews of subsets of CPAN, which have a side-effect of
adding the appropriate meta-data to CPAN.
4. Clarification for new users of how the CPAN (and perl) work.
5. Agreement on what meta-data is required.
6. A site (or section of CPAN) where reviews can be posted.
I volunteer to provide (4). That probably requires me to look at the
existing PAUSE interface and understand it. It may take some time.
> > Concisely, I think the best solution is to add some restrictions at the
> > upload interface. To be consistent with TMTOWTDI, these would not
> > It still looks like a big job to me.
> A new CPAN... isn't it the chicken-and-the-egg problem?
Please re-read what I wrote ... I should have been more clear.
I suggested a change to the upload interface. It is not really
necessary to clone cpan to do this but it might be necessary to
demonstrate its utility in order to sell the idea.
> > A quick solution to this problem would be a clear explanation at the top
> > of the CPAN site since, I don't think the search interfaces include all
> > three categories (but I'm often wrong in what I think :-).
> Most of my modules do not have registered namespaces, and I don't have any
> problems finding them using search.cpan.org. And I find a lot of useful
> relatively-unknown modules by other authors that way too.
Finding modules is not a problem for module authors. It is a problem
for module users and prospective module authors.
You already are clear on what the categories are (registered versus
non-) but I am not because the only explanation is buried in the PAUSE
documentation somewhere (i guess) rather than there being a link to it
at the top of the CPAN search engine.
> Shlomi Fish
> Shlomi Fish firstname.lastname@example.org
> Homepage: http://www.shlomifish.org/
> I'm not an actor - I just play one on T.V.