On Mon, May 26, 2008 at 07:29:14PM -0400, David Golden wrote:
> On Mon, May 26, 2008 at 6:10 PM, Eric Wilhelm
> <[EMAIL PROTECTED]> wrote:
> 
> > It's no different than requiring Extutils::MakeMaker to be installed, so
> > it's not really a bootstrapping problem as much as one of outdated
> > assumptions, but in either case it seems to be the norm to test with an
> > outdated (they call it "stock" toolchain), so the signal/noise ratio is
> > roughly zero.
> 
> That's only a failing of CPANPLUS/CPAN::YACSmoke.
> CPAN::Reporter::Smoker requires Module::Build because I think a smoke
> test should assume a relatively modern toolchain.  In my opinion,
> smoke testing "bare metal" installs of years-old Perl doesn't add a
> lot of value.

Sorry David, but I have to take exception to that. It is not a failing
of the YACSmoke toolchain, as we try and keep prerequisites to a minimum
on purpose.

Forcing testers to upgrade to the latest and greatest of everything is
not going to give the tester/author an understanding of what the 'user'
is going to experience when they install a distribution.

If an author doesn't wish their distribution to work with older perls
then let them specify it. If the user is going to experience a problem
with an installation because it doesn't have Module::Build, or some
other up to date distribution, then personally I would want to know
that, and try and fix the installation so that it does work on older
perls.

As we've mentioned in a thread on the cpan-testers-discuss list, many
companies have a slow upgrade policy, or have to work with a particular
version because it's stable for them.

Reading a summary line with a FAIL report count, and not investigating
whether it's applicable to you, is missing the point of CPAN Testers
entirely.


However, to address Eric's initial questions:

At the moment you cannot challenge a report, in the manner that it could
be deleted if incorrect. This has been discussed for the future, but may
take some time to implement, and will require the newer HTTP interface,
which s currently under development.

'chris' is indeed Chris Williams ([EMAIL PROTECTED]), who is a very
nice guy, and is very helpful in trying to get to the bottom of
problems.

The problem with reading the Web interface of the NNTP posts, is that it
automatically hides the email address of the tester to prevent spam
attackes. This has been the case for many years. I may investigate some
interactive form on the CPAN Testers Statistics site that allows you to
see the real contact address if you enter the NNTP id (1522795 in your
case).

The reason it "helpfully" tells you about updating Makefile.PL is
because Makefile.PL has been the default for many years, and Rob and I
haven't had the time to devote to YACSmoke to update that part of the
automated message. I will look at changing that to be applicable to both
installers.

> The sad thing is that these erroneous test results make it appear as
> though my module has unresolved problems. 

On Perl 5.6.2, which your 2 examples were tested on, quite likely it
does. The tester is trying to test as close to the real user experience
as possible, if they're experiencing problems, then a user will also
likely suffer the same problem on the same platform. Hence why it's
important to investigate whether the report is applicable to you. In
this instance it fails on Perl 5.6.2, that's useful to anyone needing to
use that version of Perl.

If Module::Build wasn't installed, it should have used
ExtUtils::MakeMaker, but for whatever reason that didn't happen, and it
might be worth chatting to Chris to understand better why.

Cheers,
Barbie.
-- 
Birmingham Perl Mongers <http://birmingham.pm.org>
Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>


Reply via email to