On Thu, Sep 04, 2008 at 12:18:57AM +0100, Barbie wrote: > 3) Build/Make FAILs > > However, there are situations where the author gets it wrong, either in > the build or the make stage. How can we discern the difference? To some > we should ignore those reports too as they are of no use. However, in > many situations I believe they are, as it's how we come to understand > why the NA report has more value. It has also highlight some really bad > magic some authors put into their build files. > > Going back to Graham's vision, perhaps UNKNOWN is appropriate here.
I'd not want to overload the meaning of 'unknown' here. Splitting FAIL into PL_FAIL, MAKE_FAIL and (TEST_)FAIL would be better, I think. This is partly because CPANdeps assumes that UNKNOWN means that the module will install, for the purposes of calculating its half-arsed probability of success. However, PL_FAIL and MAKE_FAIL should never be sent automatically - they should receive at least a cursory look from the tester, as they are almost always things like trying to install DBD::mysql without the MySQL libraries and headers. > This has been much more of a problem in > recent times as many of the testers have recently built new environment > and are testing all of CPAN. Are they? I did this historically, but only for what looked like the most recent version of each distribution. I stopped a long time ago. > least for now. Personally I don't use any feed reader, and I suspect I'm > not alone, so cutting off emails completely right now is likely to get > FAIL reports going unnoticed by the very authors we actually want to > reach. I expect there is a work-around possible, generating both emails and RSS from the same data, whichever the author in question prefers. We could even generate the emails from RSS, using something like rss2email. -- David Cantrell | Reality Engineer, Ministry of Information Do not be afraid of cooking, as your ingredients will know and misbehave -- Fergus Henderson
