Eric Roode wrote:
[meta: I apologize in advance if this is a FAQ, but I could not get to
mail-archive.com to search the group's archive]
Can one challenge the result of a CPAN-testers test result? If so, how?
No.
I see several erroneous FAIL reports for modules of mine, and I think
it's unfair that it appears as though my module(s) have failures or
outstanding bugs.
I wouldn't worry about the apparent unfairness of it. People who care
enough to look at the eventual errors reported against a module are
sufficiently intelligent to determine whether or not the error applies
to them.
I have a couple of FreeBSD-specific modules. Automated smokers running
on Linux and what ever keep trying to test them and fail. I don't think
these failures will stop someone who uses FreeBSD from considering them
for their own use.
Here's an example: report 1522795,
http://www.nntp.perl.org/group/perl.cpan.testers/2008/05/msg1522795.html
About 2/3 of the way down in the report, there are the following
lines:
[MSG] [Mon May 26 01:20:29 2008] Ok, not sending test report
[ERROR] [Mon May 26 01:20:32 2008] MAKE failed: cp lib/Regexp/Common/time.pm
blib/lib/Regexp/Common/time.pm
Manifying blib/man3/Regexp::Common::time.3
/home/cpan/perl562/bin/perl "-Iblib/arch" "-Iblib/lib" Build.PL Build
Too early to specify a build action 'Build'. Do 'Build Build' instead.
gmake: *** [Build] Error 2
On the first line above, we see that the tester is not sending a test
report to the author (me). Why? On the fourth line above, we see
Because if there's one thing that makes an author even more irate that
finding out that their module failed on someone else's setup, it's
having their nose rubbed in the fact and having their inbox spammed. We
stopped doing that a long time ago.
that the tester's script is incorrectly invoking Build.PL. Why?
So far as I can tell, I have no way of contacting the tester who
generated this report. The top of the report simply says:
From: chris
Date: May 25, 2008 17:20
Subject: FAIL Regexp-Common-time-0.03 i386-netbsd-thread-multi-64int 3.1
Who is "chris", and how do I contact him or her?
Taking a guess based on statistical probabilities, I would say that this
would be Chris "Kidney Bingos" Williams.
Here's another example: test report 1522754,
http://www.nntp.perl.org/group/perl.cpan.testers/2008/05/msg1522754.html
/Volumes/Media/smoke/perl562/bin/perl "-Iblib/arch" "-Iblib/lib" Build.PL Build
Can't locate Module/Build.pm in @INC (@INC contains: [deleted by eric]) at
Build.PL line 3.
BEGIN failed--compilation aborted at Build.PL line 3.
make: *** [Build] Error 2
MISSING PREREQUISITES:
It was observed that the test suite seem to fail without these modules:
Module::Build
As such, adding the prerequisite module(s) to 'PREREQ_PM' in your
Makefile.PL should solve this problem. For example:
The test suite not only incorrectly invoked Build.PL, it failed
because Module::Build is not installed, and then "helpfully" tells me
how to update Makefile.PL so as to avoid the problem! How ridiculous!
(My modules include both Build.PL and Makefile.PL, so users can have
a choice about how to install).
The sad thing is that these erroneous test results make it appear as
though my module has unresolved problems. I've been searching the web
for the past hour or two, and I can find no information about how to
contest a cpan-testers result, or to get an erroneous FAIL result
removed from my module's record.
Relax, no-one will think any less of your modules simply because they
acquire a couple of FAIL reports. The more complex a module is, the more
likely it is to fail somewhere.
There is a long-standing discussion over whether or not Module::Build is
a viable installation technique, due to the bootstrapping problem of
requiring Module::Build to be installed in the first place before
installing your own module. The question is whether a vanilla
out-of-the-box 5.8.8 installation can install your module without any
toolchain component needing to be installed beforehand.
Now that Module::Build is bundled with 5.10, we may hope that the
problems surrounding this issue will begin to subside.
If you heed the advice given in the other replies, you should be able to
improve the successful testing of your module. In that case, you just
have to release a new version!
Can anyone help?
Thanks,
Eric Roode
Regards,
David
--
stubborn tiny lights vs. clustering darkness forever ok?
