On Sun, Feb 15, 2004 at 03:56:39PM +1300, Sam Vilain wrote:
>   ___                 
>  / _ \
> | | | |_  _ ____ ____ 
> | |_| ||\ | |    |___ 
>  \___/ | \| |___ |___ upon a time, the Perl 5 modules list was an
> excellent resource for those seeking to do anything non-core with
> Perl.  However, it has not kept pace adequately with the needs of the
> community.

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 propose, what we do about this situation is :
>   - expand the modules list into a new section of the www.cpan.org
>     site, by;
>   - deciding if the current categories are good enough 'in this day
>     and age'; using the current list as a starting point, go through
>     each category and decide whether it is a useful grouping any more.
>     This will ideally also involve individuals with experience with
>     other languages trawling over the appropriate CPAN equivalents, ie
>     PEAR, RAA, etc, and providing nice, *brief*, informative reports
>     on their structure.
>     We will then hopefully have a half-decent list of categories.
>     This process should be quick, perhaps reporting back its progress
>     to the list every few days until there is a general consensus.


>   - encourage curators to step forward, or groups of curators, for
>     each category; possibly even create mailing lists for people with
>     a general interest in the technology in that category; to field
>     questions about naming for new modules to fit into each category.
>     These curators must have the power to update the contents of the
>     relevant portions of the www.cpan.org site.
>     The idea would be to have each category something like the
>     http://poop.sourceforge.net/ site - but on a standard template to
>     lend it more credibility.  Ideally with space for user feedback.
> I would hesitate to seed the listing of actual modules on the current
> long Perl 5 modules list.  Factors such as the usage that the module
> has seen, whether long standing bugs were ever fixed, whether a better
> module has come along since and gained widespread acceptance, etc need
> to be taken into consideration.

I disagree. You're mixing different goals that ought to be kept separate.

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.

You could argue that Goal 1 is now largely addressed by searching
search.cpan.org (although that's certainly not without problems).

However the limited integration with the Module List's hierarchical
categories and other metadata is unfortunate. I think that's partly
due to Graham Barr's view (as I remember it, I might be wrong here)
that the Module List was too incomplete relative to the whole of
CPAN to be useful and he's right.  So let's fix that - see below.

Goal 2 is still important - as you can see from archives of
[EMAIL PROTECTED] when there have been discussions leading to a
better choice of module name. But [EMAIL PROTECTED] has it's own set
of problems (that I hope will be addressed when it's integrated
with RT so requests don't fall between the cracks).

> Many popular modules are missing from the list altogether.

The text file is out of date. The underlying database isn't:


(Though it is incomplete because not enough authors take the steps
to get listed, but that's a different set of issues.)

Please work with the PAUSE system, and Andreas and myself, to
enhance what already exists (which includes a UI for module authors
to pick which category they want the module in).

Here's what I'd suggest:

0. Don't underestimate how difficult and subtle naming issues can be.

1. Split and extend the list of categories
        aiming for about 2 to 3 times the number to keep it managable,
        perhaps grouping the categories into a two-level hierarchy
        (but the top level is just for human use, the 2nd level names
        should be self-descriptive without the 2st level names).

2. Map modules from the old categories to the new ones
        This needs to end up as a sequence of SQL statements that
        can be run on the PAUSE mysql db to update the category number
        for each module that has one.

3. Write a script to generate http://www.cpan.org/modules/00modlist.long.html
        from http://www.cpan.org/modules/03modlist.data.gz
        or ideally from the underlying mysql database
        (with simpler formatting and focussing on just the modules)
        and give it to Andreas for PAUSE to use automatically.

4. http://www.cpan.org/modules/03modlist.data.gz is actually a perl module
        called CPAN::Modulelist but it's nor downloadable as a module.
        I think it would be good if it was. Give it a YYYYMMDD version.
        That's for Andreas to do, I guess.

5. This is a key one... For those modules that are not on the Module List,
        (i.e., not in http://www.cpan.org/modules/03modlist.data.gz)
        and which have a 'significant' existing user base, develop
        a "Fast Track" process to get them added to the Module List.
        The key point here is that modules with a significant
        existing user base can't easily be renamed so we might as
        well live with the names they have.


Reply via email to