Re: OK, so we've decided that the right modules are too hard to find.

2004-02-16 Thread khemir nadim
Sam Vilain [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]

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

Hi all,

Everything that was said in this thread was very interresting and I, too,
belive things should get better and I encourage those that want to do things
_now_.

I see few problems with CPAN, you might find them directly related to the
need for curators:

- Any one can start whatever hierarchy
- Anyone can load whatever piece of code to CPAN, good or bad
- Documentation level is a catastrophy, check how many readme are those
generated by h2xs
- The document about how to use CPAN is not clear enough or I haven't found
the right one yet
- 25 versions of the same module do no make it easy to look around in CPAN
- Authors don't answer or have given up on maintaining there modules
- The same day, the same module can be uploaded to CPAN multiple times

I mirror CPAN at home and I check for new modules everyday. Guess how many
times I think what the Hell is this for???

Far from me the idea to refuse uploading of modules to CPAN but 3 years from
now, we'll have a useless module heap.  If there is a need for curators, I
believe it does, then those should be given a mandat and power to apply it
or it will be useless. They must be able to say to a module author: Sorry
but this is not the quality level we expect, write some documentation and
come back later for your upload. This is exactly what is done for moderated
mailling lists.

The net result would be (IMO):
- No half baked idea, modules on CPAN (could be a good idea to go through
what we have today in CPAN and throw away things)
- Better quality in the documentation and test (hmm, I'd have to work on my
own modules too)
- More people involved in this mailling list (which has less than 20 active
users) since it would be the way in to CPAN

Around 15 new, or updates, modules are uploaded to CPAN everyday.

This might sound drastic but it is not as bad as it sounds, I would have
appreciated if someone said 'No' to something I write and that is not good
enough for the community. This is not for discouraging module authors but,
on the contrary, make them feel that their work is appreciated and that they
must commit themselves to generate something good enough.

Moderators rights should be:
- Create new hierarchy roots
- Refuse a module name
- Refuse a module because its quality is too low
- Refuse a module because of lack of documentation or tests or examples (or
VERSION!!!)
- Give maintenance rights
- Try to merge modules by asking module authors to co-operate
- Write public review or accept public reviews
- Coordinate with module testers
- etc ...

I am whilling to have my modules filtered, I hope other do too. I'll also
help if I can.

Cheers, Nadim.

PS: PPM modules vs plain module problems should be fixed too.









Re: OK, so we've decided that the right modules are too hard to find.

2004-02-16 Thread Simon Cozens
[EMAIL PROTECTED] (Khemir Nadim) writes:
 Everything that was said in this thread was very interresting and I, too,
 belive things should get better and I encourage those that want to do things
 _now_.

None of these ideas are new.

 - Any one can start whatever hierarchy

This is not a problem, now we have search.cpan.org.

 - Anyone can load whatever piece of code to CPAN, good or bad

I don't agree that this is a problem.

 - Documentation level is a catastrophy, check how many readme are those
 generated by h2xs

But the generation was added to h2xs because people weren't putting in 
READMEs, and so an autogenerated one is better than nothing!

 - The document about how to use CPAN is not clear enough or I haven't found
 the right one yet

You haven't found the right one yet.

 - 25 versions of the same module do no make it easy to look around in CPAN

This is not a problem now we have search.cpan.org.

 - Authors don't answer or have given up on maintaining there modules

THEY ARE VOLUNTEERS.

 - The same day, the same module can be uploaded to CPAN multiple times

Yes, module authors can fix bugs quickly. How terrible!

 Far from me the idea to refuse uploading of modules to CPAN but 3 years from
 now, we'll have a useless module heap.  If there is a need for curators, I
 believe it does, then those should be given a mandat and power to apply it
 or it will be useless.

*We have been through this*. Innumerable times. Still nothing happened.

The people most likely to act as curators got together (as they do
periodically) and decided that better metadata would be the best short-term
goal. I'll try and get some of them to write up the latest set of proposals.

-- 
The best index to a person's character is a) how he treats people who can't 
do him any good and b) how he treats people who can't fight back.
-- Abigail Van Buren


Re: OK, so we've decided that the right modules are too hard to find.

2004-02-16 Thread khemir nadim
Simon, Can you please give us serious answers. Writting to this list take
valuable time from me and from those reading the mails.

  - Authors don't answer or have given up on maintaining there modules
 THEY ARE VOLUNTEERS.

Please don't shout if it's note to show you're happy. Check the discussion
we had about Roman.pm a few weeks ago. My point is not to force anyone to
develop anything but that when a module is released and the author can't
maintain it, the curators job would be to design a new maintainer. Period.

Now, surf to: http://search.cpan.org/recent

and check:

Haver-Server-0.02 -- Perl extension for blah blah blah

You might think it's OK but I don't.

Here is an example of what changed from version 0.07 to 0.08 for a module
(loaded 10 mn after 0.07)

0.08Sun Feb 16 16:21:00 2004
Fixed MANIFEST for test.pl

Everybody makes mistakes. I just would like to help people not do this kind
of mistakes.

Since I have missed the document, you might be able to point to it instead
for telling me that I have missed it. And no, sear.cpan.org isn't a silver
bullet though I use it more than cpan.org.

Cheers, Nadim.

Simon Cozens [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
 [EMAIL PROTECTED] (Khemir Nadim) writes:
  Everything that was said in this thread was very interresting and I,
too,
  belive things should get better and I encourage those that want to do
things
  _now_.

 None of these ideas are new.

  - Any one can start whatever hierarchy

 This is not a problem, now we have search.cpan.org.

  - Anyone can load whatever piece of code to CPAN, good or bad

 I don't agree that this is a problem.

  - Documentation level is a catastrophy, check how many readme are those
  generated by h2xs

 But the generation was added to h2xs because people weren't putting in
 READMEs, and so an autogenerated one is better than nothing!

  - The document about how to use CPAN is not clear enough or I haven't
found
  the right one yet

 You haven't found the right one yet.

  - 25 versions of the same module do no make it easy to look around in
CPAN

 This is not a problem now we have search.cpan.org.

  - Authors don't answer or have given up on maintaining there modules

 THEY ARE VOLUNTEERS.

  - The same day, the same module can be uploaded to CPAN multiple times

 Yes, module authors can fix bugs quickly. How terrible!

  Far from me the idea to refuse uploading of modules to CPAN but 3 years
from
  now, we'll have a useless module heap.  If there is a need for
curators, I
  believe it does, then those should be given a mandat and power to apply
it
  or it will be useless.

 *We have been through this*. Innumerable times. Still nothing happened.

 The people most likely to act as curators got together (as they do
 periodically) and decided that better metadata would be the best
short-term
 goal. I'll try and get some of them to write up the latest set of
proposals.

 -- 
 The best index to a person's character is a) how he treats people who
can't
 do him any good and b) how he treats people who can't fight back.
 -- Abigail Van Buren




Re: OK, so we've decided that the right modules are too hard to find.

2004-02-16 Thread Michel Rodriguez
On Mon, 16 Feb 2004, khemir nadim wrote:

 Please don't shout if it's note to show you're happy. Check the discussion
 we had about Roman.pm a few weeks ago. My point is not to force anyone to
 develop anything but that when a module is released and the author can't
 maintain it, the curators job would be to design a new maintainer. Period.

Going back to Roman.pm (I was on vacation when you first posted, hence no
answer at the time), if a PAUSE admin wants the email of the original
creator, (he seems a bit paranoiac about letting it displayed in the
wwwild), I have it, so he can gain the rights to maintain his own module
;--)

--
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com



Re: OK, so we've decided that the right modules are too hard to find.

2004-02-15 Thread Tim Bunce
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.

Okay.

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

  http://www.cpan.org/modules/03modlist.data.gz

(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 

Re: OK, so we've decided that the right modules are too hard to find.

2004-02-15 Thread Johan Vromans
Tim Bunce [EMAIL PROTECTED] writes:

 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.

Good idea, but don't we need to solve the current module registry
problems as well? Many module authors issue submission requests and
never get a reply.

-- Johan


Re: OK, so we've decided that the right modules are too hard to find.

2004-02-15 Thread Elizabeth Mattijsen
At 13:57 +0100 2/15/04, Johan Vromans wrote:
Tim Bunce [EMAIL PROTECTED] writes:
  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.
Good idea, but don't we need to solve the current module registry
problems as well? Many module authors issue submission requests and
never get a reply.
I've released about 30 modules in the past 1.5 years.  I _never_ 
bothered to try to register.  I guess that means something.

Liz


Re: OK, so we've decided that the right modules are too hard to find.

2004-02-15 Thread Simon Cozens
[EMAIL PROTECTED] (Johan Vromans) writes:
 Good idea, but don't we need to solve the current module registry
 problems as well? Many module authors issue submission requests and
 never get a reply.

Tim also wrote:
 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)

-- 
Oh dear. I've just realised that my fvwm config lasted longer than my
marriage, in that case.
- Anonymous


Re: OK, so we've decided that the right modules are too hard to find.

2004-02-15 Thread Simon Cozens
[EMAIL PROTECTED] (Elizabeth Mattijsen) writes:
 I've released about 30 modules in the past 1.5 years.  I _never_
 bothered to try to register.  I guess that means something.

Likewise. (although slightly more than 30 ;) 

I just don't see the point of the modules list, especially now we have
search.cpan.org.

-- 
When Simon Cozens writes code, I always think twice about whether
something is a bug or an esoteric implementation.
- Daniel Packer