Adam Kennedy wrote:
Whether or not that is a transient thing that lasts for a week, or a
serious and ongoing problem, I think it's still worth it.
But that would require regular scanning -- otherwise I might get the
point one week and then a dependency might upgrade in a way that is
borked. (Test::Exception did this to me a while back for some
particular version of it -- actually related to CPANPLUS not recognizing
Module::Build's build_requires... and on we merrily go.)
More to the point, it should lead people to spend more time looking into
WHY their module isn't installing, and help us nail down the critical
modules in the CPAN toolchain that have problems.
I agree. I've been stripping Test::Exception. The syntactic sugar isn't
worth the headache of diagnosing build failures.
If all of a sudden you lose the clean_install point, you can go find the
problem, then either help the author fix the problem or stop using that
module. Either way, your module used to not install, and now it does
install.
(*If* the author fixes the problem. I still can't get my patches for
Sub::Uplevel high enough in Schwern's queue. But that goes back to your
point about dodgy dependencies, so I'll score that argument to you.)
A testing system should only be sending FAIL reports when it believes it
has a platform that is compatible with the needs of the module, but when
it tries to install tests fail.
General question: Are failed prerequisite versions a FAIL or a Not
Applicable if the smoke tester isn't set to automatically try to upgrade
them?
I'm interested to hear what some the special cases might be though. I'm
trying to put together a mental list of possible problems I need to deal
with.
You need to deal with N/A's down the chain. E.g. I prereq a module that
can't be built in an automated fashion but requires human intervention
or choices or external libraries. If you don't have it and the
automated build to try to get it fails, that really isn't my problem --
I've been clear about the dependency: "If you have version X.YZ of
Module ABC::DEF, then I promise to pass my tests".
Think about the GD modules -- if the GD library isn't installed, GD
won't build and anything depending on it fails. Should that fail a
"clean_install"?
(Contrast that with SQLite, which installs it for you.)
A FAIL should ONLY mean that some package has told the smoke system that
thinks it should be able to pass on your platform, and then it doesn't.
Failures that aren't the fault of the code (platform not compatible, or
whatever) should be N/A or something else.
I think better granularity would be: "FAIL" -- failed its own test
suite; "DEPFAIL" -- couldn't get dependencies to pass their test suites;
and "N/A" -- incompatible platform or Perl version or not automatically
chasing dependencies.
If you want to help out, we'd love to see you in irc.perl.net #pita.
Between tuit shortages and the day job (side q: what's this whole $job
thing I keep seeing in people's posts/blogs), a realtime channel like
IRC is hard to keep up with. Is there a mailing list or wiki or some
such? (Subversion repository?)
Regards,
David
