On Mon, Sep 21, 2009 at 12:13 AM, <cr...@animalhead.com> wrote: >> Most automated smoke testing will just quietly exit and continue. The >> testers will never see the prompt. This is generally how automated >> testers like it (though there are exceptions). Stopping at every Nth >> module to figure out how to resolve someone's custom dependency takes >> extra time that donating some CPU cycles to the testing effort does >> not. > > The idea that you and http://wiki.cpantesters.org/wiki/CPANAuthorNotes > would recommend Devel::CheckLib as a means to handle a dependency on a > C library, and that the smoke testing SW does not pick up on its > output and tell the tester about the dependency, is slightly mind- > boggling.
It's a compromise. You and other authors don't like seeing FAIL and UNKNOWN reports when a dependency couldn't be met. But CPAN Testers is a decentralized, volunteer effort. Adding a new grade "NOPREREQ" or whatever would mean writing a bunch of code, getting "everyone" to upgrade and so on. We discovered that "exit 0" would shortcut the process. It was an immediate fix with no code to write and supported by all known versions of CPAN/PLUS. Perhaps in the future, this will change. >> Just for the record, I've installed it now and will attempt to send a >> test report. What I've noticed so far is that some of the test files >> are very slow and in other circumstances I might have hit CTRL-C by >> now. You might want to warn( "# this test may take a long time to >> finish\n") or something for the longer-running test files. > > That sounds fishy. Here's the ending line from make test on my server: > Files=10, Tests=6744, 3 wallclock secs ( 1.12 usr 0.18 sys + 1.87 cusr > 0.43 csys = 3.60 CPU) > Or is your CTRL-C finger really twitchy? It was probably 30 wall clock seconds for me. I'll send you output off-list. > On the flip side, I just found a new version of ExtUtils::ParseXS > (which I require to avoid certain false error messages), in which the > Changes file says: > >> 2.200401 - Mon Sep 14 22:26:03 EDT 2009 >> - No changes from 2.20_04. > > > Which makes me feel like version number selection is like playing the > stock market. Which I'm also not good at... I use a very specific pattern. In this case, chronologically: * 2.20 - stable release * 2.20_01 - dev release * 2.2002 - Makefile.PL fix -- "stable" release bump for Perl 5.10.1 core * 2.20_03 - dev release * 2.20_04 - dev release * 2.20_05 - dev release (lots of FAIL here, though) A special request was made from some authors to get a new release out to fix a major bug on 5.8 series perls. I judged 2.20_05 too unstable to release, so went back to 2.20_04 as the best candidate for a stable release * 2.200401 Davi
