Re^3: cpan and (dual-nature) scripts?

Thanx for giving it a review, dolmen. Any takers for my naming/category issue :)?

I've updated my local Build.PL's build_requires (=>0,), thanx for the tip.

(and yes, the amount of test green also surprised me)

As for the tests, I might go from really very light to just fairly light, but a realistic portable testset to be run from CPAN.pm just doesn't seem quite realistic to me:

Portability for some of waitconds functionality like iostat (diskidle) is one problem, writing a portable test for that is another, quite worse one. Plus the 30 second delay required to get something at least somewhat sane out of iostat...

I've added to the todolist e.g. 'check ps test + add e.g. psid / pscmd to test against only a major ps field'. Which is probably a good idea for having the cpan testers do some more portability testing for me. I think I'll just intentionally add some tests and risk failures for some parts intentionally, e.g. a missing command or command capability on some platforms (something like ping w/o -c 3 or lack of GNU ps, and then just document them (or document + skip the test on known bad platforms with lacking os functionality?).

Things like having waitcond grep a logfile is a trivial one to add, as is testing some boleans over the more primitive tests. If I add a touch and a subsequent sleep 2 to the testscript in front of waitcond, I can also test 'idle' and 'recent'. Some other ops also allow 'light tests' when I don't allow waitcond to wait for/timeout on a condition. diskidle or netidle are probably no-go areas, too slow, heavy and too much of a base-os-install-sanity test.

Maybe I'll write and add some of the heavier/realistic testscripts to some non-cpan-test dir like contrib, in case a user wants to track down some bug, or provide an os-specific patch for some Unix or even cygwin. I probably also should add things to contrib (examples?), like the DBUS-Usage-sketch I played with. Currently only on github.

And I still have to figure out how to efficiently include cpan in my push-updates process, locally and to github (no, waitcond isn't i a git of it's own (thus the github whole-repo-tarball-fetch-url via PAUSE won't work except as DOS); also, the script-archive git at github is used for archival/publishing, but not so much for source control (yet, but if I ever go there for real, I might just move some stuff into git's of their own)). I wonder how - in the end - I will have 'root-noded' that repo-dependency graph properly :>.

Btw1, is there some Perl standard distribution location for such extra stuff, to get it installed in the filesystem, but out of the way? Other than say just occupying /usr/local/share/doc/waitcond_cpan_distribution? (and anything /usr requires being root or a sudo prefix in the CPAN.pm config, something I'm also not that happy about)

q2, is there a way to add cygwin (but not pure windows) as an os for the cpan testers?

q3, my current understanding is that the tests may be automated, but the report may also be manually augmented(?) to contain some additional information and comments. Are such augmented/more valuable reports marked or filterable in some way? Or do I have to hope for the tester to fail the test, or add an email so I at least won't miss his comments/reviews?

Comment on Re^3: cpan and (dual-nature) scripts?