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
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
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.