develooper Front page | perl.qa | Postings from March 2017

BBC testing from upriver downwards

Thread Next
From:
James E Keenan
Date:
March 17, 2017 21:32
Subject:
BBC testing from upriver downwards
Message ID:
20170317213221.11970.qmail@lists-nntp.develooper.com
perl-5.25.11 will be released on Monday March 20.  Since this will be 
the first monthly dev release to reflect the banishment of '.' from the 
default @INC, it is the first monthly release in which we can assess the 
effect of that change on CPAN.

Up until now we've mainly relied on Andreas and Slaven's CPAN tester 
reports in this regard.  But we have a problem.  We're having problems 
with cpantesters.org such that, while we rapidly get PASS/FAIL 
indicators for a given distro on a given platform on a given version of 
perl at fast-matrix.cpantesters.org, we are having big delays at getting 
the full report of a test failure at matrix.cpantesters.org.  Currently, 
'matrix' is behind 'fast-matrix' by ... more than a few days.

I know that Doug Bell++ and others are examining this problem, but I 
would like to try some modest workarounds.  What I would like to do is:

1. Compose a list of CPAN distros starting with those farthest up river, 
i.e., distros that only depend on the perl 5 core.  Within that set of 
distros I'd like to order them from most reverse dependencies to fewest. 
  Then go down river from there.

2. Get an up-to-date minicpan.

3. Use that minicpan as the source of tests of the CPAN distros.

4. Run something like a full CPAN test for perl 5.25.11 -- but be able 
to cut that off at either a certain number of distros -- e.g., the 5000 
farthest upriver -- or at a certain number of level below the core itself.
(a) I would like the location where the tests are run, the version of 
'cpan', 'cpaniminus', etc. to be completely distinct from whatever my 
"usual" procedure is on a given platform -- that so I can just blow away 
everything I've done once I'm through.

5. Capture reports of test failures so that we can identify their cause 
-- e.g., is this failure due to:

(a) no '.' by default in @INC?
(b) some other change during 5.25.x development?
(c) breakage, not yet corrected, from some change in an earlier perl 
major release?
(d) bad code in the CPAN distro?

I don't want to re-invent the wheel here.  Do we have prior art for this?

Thank you very much.
Jim Keenan

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About