[EMAIL PROTECTED] (Adam Turoff) wrote:
>Allow me to clarify -- I'm interested in hacking the cpan-testers data.
>This will most likely lead to a facelift for testers.cpan.org.  :-)
>
>Graham asked me to discuss the changes I'd like to see with the 
>testers site.  Here's what I have in mind:
>
>  - Provide a downloadable version of the test database (generated 
>    periodically, much like http://dmoz.org/rdf).  
>
>  - Provide summaries by module of the entire test history for
>    that module in a single file:
>      - module version tested
>      - Perl version tested (perl -V output, and parsed configuration)
>      - OS (+platform) tested
>
>  - Provide brief summaries of what modules have been tested by
>    Perl release
>
>  - Provide cross-reference pass/fail reports based on Perl configuration
>    option and release
>
>  - Output should be available in multiple formats: XML, Text, and
>    if this does wind up being a facelift for testers.perl.org, HTML.  :-)

I would add to that:

   - Enhancement of cpantest.pl so that testers can easily check the
     testing history of a module on their platform

The reason is that I generally just submit test results blindly, without
checking whether someone else has already reported a particular
package/version/platform combination.  This works okay for me because I
seem to be the only one reporting tests for the Darwin platform, but it
would be nice to be assured that I'm not reporting redundant data.

>Ideally, a rich API layer could be added on top of testers.cpan.org, so
>that an install client (CPAN.pm) can provide relevant test information
>to a user before a module is installed.

Agreed.  And it would be nice to build the cpantest.pl functionality
into CPAN.pm too, for those that want it.

>Maintaining a local copy of the (relevant) test data could help
>smoke-test clients burn through a local CPAN mirror and torture test
>CPAN.

One might need to maintain a list of modules that can't just be
downloaded and tested without some additional manual system
configuration, because these may well fail in a rapid-fire smoke test.
This includes modules like GD.pm (requires several external libraries)
or HTML::Mason (has interactive 'make test').


  -------------------                            -------------------
  Ken Williams                             Last Bastion of Euclidity
  [EMAIL PROTECTED]                            The Math Forum

Reply via email to