Apologies to the list; I mistakenly sent this rant to Gabor Szabo
only, when I meant to send it to the whole list for discussion.
-- Eric
-- Forwarded message --
From: Eric Roode [EMAIL PROTECTED]
Date: Tue, Jun 10, 2008 at 11:01 AM
Subject: Re: New CPANTS metrics
To: Gabor
On Tue, 10 Jun 2008, Eric Roode wrote:
* Then there are these, which are probably valid metrics, but of
questionable utility:
buildtool_not_executable: Nearly everyone does perl Makefile.PL
or perl Build.PL. Note that this does not specify a specific perl,
just the first one in the user's
On Tue, Jun 10, 2008 at 11:03:33AM -0400, Eric Roode wrote:
I do not wish to rain on anyone's parade, and I do not wish to
quash anyone's enthusiasm for improving Perl or its wide-ranging
library of modules. However:
I cannot for the life of me figure out what sort of value there is
On Jun 10, 2008, at 10:41 AM, David Cantrell wrote:
If you see no value in it, just ignore it. I'm sure it will do
wonders
for your blood pressure.
I guess that's my very point. Here's this entire subsystem that
exists to supposedly give information to authors and potential users
On Tue, Jun 10, 2008 at 11:47 AM, Andy Lester [EMAIL PROTECTED] wrote:
On Jun 10, 2008, at 10:41 AM, David Cantrell wrote:
If you see no value in it, just ignore it. I'm sure it will do wonders
for your blood pressure.
I guess that's my very point. Here's this entire subsystem that
On Tue, Jun 10, 2008 at 11:47 AM, Andy Lester [EMAIL PROTECTED] wrote:
I guess that's my very point. Here's this entire subsystem that exists to
supposedly give information to authors and potential users about the
relative quality of the code, and yet the attitude that comes out is Eh, we
On Tue, Jun 10, 2008 at 11:20 AM, Dave Rolsky [EMAIL PROTECTED] wrote:
[...]
Again, see above. These points codify existing community standards. The
reason this is not much of a problem now in 2008 is probably because these
standards have become so ingrained, both in terms of spreading the
In article [EMAIL PROTECTED],
David Golden [EMAIL PROTECTED] wrote:
On Mon, Jun 9, 2008 at 4:32 PM, Gabor Szabo [EMAIL PROTECTED] wrote:
I am sending this to both the module-authors list so you can be
aware of the new metrics and the perl-qa list as they might
have a few words as well
On Tue, Jun 10, 2008 at 12:27 PM, brian d foy [EMAIL PROTECTED] wrote:
I'd like to see the metircs that only talk about the quality of the
distribution, and leave everything else alone. If it's something I can
fix by doing something to the distribution itself, measure it. If it's
anything
# from Dave Rolsky
# on Tuesday 10 June 2008 08:20:
has_test_pod: Useless. Why should every end-user have to test the
correctness of the module's POD? The original developer should test
it, and the kwalitee metric should test that the module's POD is
correct (no_pod_errors). Including it
On Tue, 10 Jun 2008, Eric Wilhelm wrote:
# from Dave Rolsky
# on Tuesday 10 June 2008 08:20:
 has_test_pod: Useless.  Why should every end-user have to test the
correctness of the module's POD? Â The original developer should test
it, and the kwalitee metric should test that the module's
On Tue, Jun 10, 2008 at 1:20 PM, Eric Wilhelm
[EMAIL PROTECTED] wrote:
Perhaps. Of course, just testing the pod and pod coverage would be more
definitive and *could* certainly be done without running the code.
Not reliably. No guarantee that coverage for a function is in the
same file. I
On Tue, Jun 10, 2008 at 11:20 AM, Dave Rolsky [EMAIL PROTECTED] wrote:
[...]
You don't need to make these tests run for the end user to get the point.
All of my dists (should) ship with a pod.t and pod-coverage.t that only runs
in maintainer mode.
How do you do that, by the way? How do you
On Tue, 10 Jun 2008, Eric Roode wrote:
On Tue, Jun 10, 2008 at 11:20 AM, Dave Rolsky [EMAIL PROTECTED] wrote:
[...]
You don't need to make these tests run for the end user to get the point.
All of my dists (should) ship with a pod.t and pod-coverage.t that only runs
in maintainer mode.
How
Thanks for the info, Dave! (And thanks to you too, Jerry)
-- Eric
Hi!
Uh, wow, why do CPANTS discussions always start when I'm low on tuits...
A lot of your issues have already been addressed, and as my time is
short ATM, I'll only awnser some of the remaining
extracts_nicely: How much of a problem is this, really?
A lot of people hate
On Tue, Jun 10, 2008 at 9:51 PM, Thomas Klausner [EMAIL PROTECTED] wrote:
is_prereq is an optinal metric and thus does not count for the CPANTS
game. And yes, Apps ususally won't get prerequed. Tough luck.
Actually I'd love to be able to add some way to measure which module
is used OUTSIDE of
On Tue, Jun 10, 2008 at 2:51 PM, Thomas Klausner [EMAIL PROTECTED] wrote:
Hi!
Uh, wow, why do CPANTS discussions always start when I'm low on tuits...
Sorry :-)
extracts_nicely: How much of a problem is this, really?
A lot of people hate tarballs/zip-files that spew their content into
On Tue, Jun 10, 2008 at 10:21 PM, Eric Roode [EMAIL PROTECTED] wrote:
extracts_nicely: How much of a problem is this, really?
A lot of people hate tarballs/zip-files that spew their content into the
current dir. Especially if the offending dists contains lots of files.
Or a file with the
On Tue, Jun 10, 2008 at 3:36 PM, Gabor Szabo [EMAIL PROTECTED] wrote:
On Tue, Jun 10, 2008 at 10:21 PM, Eric Roode [EMAIL PROTECTED] wrote:
[...]
I guess it does show the end-user of a module that the module author
is smart enough not to shoot himself in the foot. The module author
might be
On Tue, Jun 10, 2008 at 10:56 PM, Eric Roode [EMAIL PROTECTED] wrote:
So I can quickly break the module. Maybe I won't even notice but
someone who uses my version will start complaining. To you...
I might be a bit more clever and add use strict and use warnings before
I start changing your
On Tue, Jun 10, 2008 at 3:21 PM, Eric Roode [EMAIL PROTECTED] wrote:
Well of course not. But use strict is simply a tool for helping
developers write modules and programs more correctly.
I guess it does show the end-user of a module that the module author
is smart enough not to shoot himself
On Tue, Jun 10, 2008 at 9:33 PM, Ricardo SIGNES
[EMAIL PROTECTED] wrote:
* Dave Rolsky [EMAIL PROTECTED] [2008-06-10T13:23:09]
The point is that you should ship a dist that is complete enough for an
end-user to untar it, hack on the distro, run all the tests, and send you a
patch.
See, I
# from Dave Rolsky
# on Tuesday 10 June 2008 10:23:
All of my dists get their pod and pod coverage tested by the
maintainer tool instead of shipping boiler-plate tests which just
happen to have certain sorts of names.
The point is that you should ship a dist that is complete enough for
an
On Tue, 10 Jun 2008, Eric Wilhelm wrote:
# from Dave Rolsky
# on Tuesday 10 June 2008 10:23:
All of my dists get their pod and pod coverage tested by the
maintainer tool instead of shipping boiler-plate tests which just
happen to have certain sorts of names.
The point is that you should
# from Dave Rolsky
# on Tuesday 10 June 2008 15:07:
If they can't be bothered to run `./Build
testpod` and `./Build testpodcoverage`, that's not such a huge deal
because it won't ship until those pass. Certainly it isn't worth me
maintaining ~100 files which might have the same content.
Dave Rolsky wrote:
On Tue, 10 Jun 2008, Eric Roode wrote:
How do you do that, by the way? How do you set it up so the test
suite knows it's you and not an end-user?
plan skip_all = 'This test is only run for the module author'
unless -d '.svn' || $ENV{IS_MAINTAINER};
Perl::Critic
27 matches
Mail list logo