in reply to The quantity vs. quality lesson
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.
|
---|
Replies are listed 'Best First'. | |
---|---|
A reply falls below the community's threshold of quality. You may see it by logging in. |