(*If* the author fixes the problem. I still can't get my patches for
Sub::Uplevel high enough in Schwern's queue.
Have you considered offering to take it over, or just co-maint the
module for one or two releases? He's given away modules before to people
that have more time to give them love than he has.
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?
Well purely logically they aren't a FAIL... I think testers currently
does email in a FAIL for the dep itself. Not sure what happens to the
parent module.
I haven't been able to find (although I haven't looked to hard) for a
documented set of result codes. But either DEPFAIL or N/A makes sense.
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.)
I _think_ that's current also dealt with ok. I can't say for sure
though. But it's such a common case I don't see why it wouldn't be.
If not, I certainly plan to deal with it that way. N/As cascade.
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.
Without knowing how many exist now, I hope to define a more
comprehensive set of HTTP-like codes, but that design element is still
flexible.
Is there a mailing list or wiki or some
such? (Subversion repository?)
No infrastructure for now, until it's actually announced, but the IRC
channel is logged ala #perl6, so you can visit when you wish, and catch
up when you care.
Adam K
