Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

autarch
  (email not shown publicly)
http://www.vegguide.org/

Journal of autarch (914)

Sunday September 17, 2006
10:19 AM

CPAN Ratings Encourages Stupidity

[ #31024 ]

Take a look at this "review" by Mark Gardner.

Now, the fact that the module fails its tests is a bad thing, indeed. However, if the only place it's "reported" is on the cpan ratings site, that doesn't really help much. Use RT or the support address in the module's docs, people!

Of course, the overlap between people who read my journal and people who write these useless "reviews" is probably close to none.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

CPAN Ratings Encourages Stupidity 11 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Granted a bug report would be nice but given DateTime::Format::DateParse looks like about 50 lines of pure perl code you really have to wonder why it has 10 fails and 3 passes on cpan testers.

    To me it seems bug reports are about getting stuff fixed and cpan ratings is about warning people about modules to avoid/encouraging people to use working/supported modules. Two very different things.
    • First, having 10 fails and 3 passes doesn't mean anything. If there is one buggy release and ten people test it, you get 10 fails. If 100 people tested it, you might have a 100 fails. The number of fails is meaningless.

      Second, my point was that if you see a test failure you should report it through channels that are likely to help the author fix it. CPAN Ratings is not that channel.
      • Sure it means something. I was only talking about the most recent release (at the time 0.2) which was released over a year ago. The ratio of pass to failure is an easy way to quantify quality. Kinda meaningless but I'm too lazy to read every line of code under DateTime.

        Saying users should do stuff is kinda like saying module authors should do stuff. In an ideal work authors and users would work together in harmonious hormonity but this aint an ideal world. If Mark wants DateTime::Format::DateParse to pass i

        • If he rants without checking whether a bug has been logged and whether the author has reacted at all (and if not, logging one and giving the author due time), then his rant is pretty well meaningless.

          I want to know what the code quality is like, and if it’s decent but has bugs, whether the author is responsive when problems arise. That is useful information.

          The fact that it fails tests isn’t anything I couldn’t see at first glance from the very same distro info page on search.cpan.o [cpan.org]

          • The rant on its own is fairly pointless but because of the review the module now passes its tests and installs correctly using CPAN. The quality of the module code hasn't been improved but the quality of the module has.

            If all a person has the time/inclination to contribute is a rant is it not better to do so than do nothing?

            • I suppose it’s better than doing nothing, although I’m not even sure about that. We’re not exactly setting the bar very high there, are we?

              But it’s still no contribution. Someone filed a bug and the author resolved it within the hour. The review rant had sat there for 5 days, accomplishing nothing.

              Then consider that registering an account on CPAN Ratings and posting a “review” requires a noticably greater committment than anonymously filing a bug. Make your own

            • No, the module got a new release and passes its tests because someone reported it on the _datetime mailing list_. In other words, someone (thanks, Simon Wistow) saw that it was failing tests, and reported it to the list as suggested in the module's SUPPORT docs.

              This led to a fixed version within a week or so.
              • To further clarify, the reason why I thought the review I pointed to was stupid was precisely because it's unlikely that the author is going to see it in a timely fashion. I only noticed it because I sometimes browse new reviews on CPAN ratings, but I don't do it all that often (once a month or less).
              • Probably was only a matter of time but I'd say it is fixed because of the 2 bugs I logged (with solutions).
                • So I guess you're agreeing with tme that using the normal bug reporting channels is the way to get bugs fixed.
                  • Sure,a much better way to get bugs fixed but cpan ratings is a much better place to rant and the most some people will do is rant.

                    Much like the fact [perl.org]
                    authors owe users nothing and do not have to do anything users owe authors nothing. Mind you this whole CPAN thingy works a lot better when both groups contribute more than the minimum.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.