I know, the issue of QA for CPAN has been brought up at least a thousand times, by far more experienced monks or perl adepts. It has also been answered that many times by even so experienced people - with the result CPAN staying CPAN.

Of course, otherwise CPAN would not be the Comprehensive Perl Archive Network, a large collection of Perl software and documentation.

But let's face it: There _IS_ crap on CPAN. And there _IS_ lots of duplicate modules and there _IS_ lots of modules whose functionality is nearly equivalent, but where you have to pick the "good one" from a set of existing. This has been discussed in length before, but evidence is, that the results of these discussions were void.

There's crap everywhere. I would not call DateTime void. I would not cpanratings void.

I wouldn't object to the theory, that the Perl community *fears*, that a rigorous evaluation and control of the CPAN modules would bring the poor condition of the CPAN repository to light.

Sure there is poor quality software there, but CPAN is practically in perfect condition (alive and well, plenty of mirrors...).

As for fear? I'm all for rigorous evaluation and it goes on all time time, but control? NO CONTROL! If you want some kind of ogre-like control, start up your own network (rejecting modules from CPAN because they aren't quality software is not smart).

how to improve quality of CPAN. This is technical detail IMHO.

I think that is http://qa.perl.org/

IMHO there is a golden way between the present laissez faire and "running the gauntlet" for module authors. My dream is, that we - the community - find and adopt it.

There is nothing stopping the community (or you) from "running the gauntlet", but it should never stop an author from uploading some shabby (not shady) software.
update: <--commented out leftover, added above sentance in its place

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.