FAQ
Is the data used for testers.cpan.org available anywhere in one
comprehensive chunk?

I looked around testers.cpan.org, and from what I can tell, it's
only available in a pre-digested report format. Surely it's
reconstructable from the cpan-testers archive, but anywhere else?

Thanks,

Z.

Search Discussions

  • Graham Barr at May 14, 2001 at 7:36 pm
    No directly, but it could be. The only place it exists as a single
    thing is in the MySQL database that tester.cpan.org works from.

    Graham.
    On Mon, May 14, 2001 at 03:27:56PM -0400, Adam Turoff wrote:
    Is the data used for testers.cpan.org available anywhere in one
    comprehensive chunk?

    I looked around testers.cpan.org, and from what I can tell, it's
    only available in a pre-digested report format. Surely it's
    reconstructable from the cpan-testers archive, but anywhere else?

    Thanks,

    Z.
  • Adam Turoff at May 15, 2001 at 1:27 am

    On Mon, May 14, 2001 at 03:27:56PM -0400, Adam Turoff wrote:
    Is the data used for testers.cpan.org available anywhere in one
    comprehensive chunk?

    I looked around testers.cpan.org, and from what I can tell, it's
    only available in a pre-digested report format. Surely it's
    reconstructable from the cpan-testers archive, but anywhere else?
    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. :-)

    Yes, this is a lot of work, and many of the test values simply aren't
    in the database yet. It's pretty much an idea to smoke test CPAN with
    various major releases (and future releases) of perl, including 5.8
    and 6.0.

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

    Thoughts? Anyone have any other ideas?

    Z.
  • Ken Williams at May 18, 2001 at 3:44 am

    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
    ken@forum.swarthmore.edu The Math Forum
  • Michael G Schwern at May 18, 2001 at 5:36 pm

    On Thu, May 17, 2001 at 10:44:59PM -0500, Ken Williams wrote:
    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.
    While its good to be aware of what has passed and what has failed,
    redundant test data is good. Just because someone reports, for
    example, "ok 5.6.1 Linux/x86" it doesn't mean it will work across
    *all* versions and configurations of Linux x86. Especially when XS
    enters the scene. It also can add more debugging information should
    it pass on one guy's setup and fail on another.

    So while we don't currently record these little environmental
    differences, it still adds confidence to have ten pass reports from
    ten different testers than only one. The cpan-tester's database
    should be able to sift and collate this data and present it in a
    non-redundant manner.


    PS Is the CC too wide?

    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl6 Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    <GuRuThuG> make a channel called #Perl, and infest it with joking and
    fun.... it doesnt make alot of sense.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedMay 14, '01 at 7:28p
activeMay 18, '01 at 5:36p
posts5
users4
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase