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>