Front page | perl.qa |
Postings from April 2017
Re: BBC testing from upriver downwards
From: James E Keenan
April 4, 2017 20:29
Re: BBC testing from upriver downwards
Message ID: firstname.lastname@example.org
On 03/30/2017 04:36 PM, James E Keenan wrote:
> 7. Wrote second perl program (attached) called 'order-battle.pl' to
> record the order in which various modules *first* appeared in the
> 'fails' file and the total number of times each module was cited.
> Results are attached as 'order-of-battle-20170330.txt'.
> What is the "order of battle"? It's the order in which, as of today, we
> need to get new CPAN releases out so that down-river distros are no
> longer failing due to failures in their upstream dependencies.
> For example, today David Golden prepared a new version of Sub::Uplevel
> -- the #1 distro in the order of battle. Once he releases that to CPAN,
> a tremendous number of downstream distros will have their prerequisites
> satisfied and -- assuming they don't have their own configure/build/test
> failures -- will become installable via this perl-5.26.0-friendly cpanm.
Over the past week I have conducted two more rounds of testing using the
approach previously discussed in this thread. I did not report on the
second round, but the third round's results subsume the second.
1. I continue to use the file which David Golden prepared last year as
a proxy for the current state of the river. I decompressed it to a
plain-text file called 'river-2016-02-27.txt'.
2. I continue to use get-upriver-distros.pl to parse the plain-text
file. However, I have modified it to try to avoid selecting the
mod_perl or Team-ReadLine-Perl distributions, as their configurations
require manual intervention; I want get-upriver-distros.pl to run by
itself for hours. (I can confirm that Term-ReadLine-Perl is
installable and 5.26.0-ready.) I am fetching the first 5000 distros
found, which were stored in another plain-text file called
3. Built and installed an updated perl5 blead for testing:
$ ./bin/perl -v | head -2 | tail -1
This is perl 5, version 26, subversion 0 (v5.26.0
(v5.25.11-27-g1b92e69)) built for x86_64-linux
... and installed Miyagawa's up-to-the-minute cpanm against that perl.
$ ./bin/perl -MApp::cpanminus -E 'say $App::cpanminus::VERSION;'
I expect this upgrade to have major benefits. Among other things, it
resolved the perl-5.26.0-compatibility of one of Miyagawa's own
$ ./bin/cpanm Plack::Middleware::Session
--> Working on Plack::Middleware::Session
Configuring Plack-Middleware-Session-0.30 ... OK
Building and testing Plack-Middleware-Session-0.30 ... OK
Successfully installed Plack-Middleware-Session-0.30
1 distribution installed
4. Adapting nudge from KENTNL, I worked from a just-updated local minicpan
date > startcpanm
cat /home/jkeenan/learn/perl/cpan-river/third-round-top-5000.txt | \
xargs bin/cpanm --mirror ~/minicpan --verbose; date > endcpanm
5. Copied and renamed the 'cpanm' build.log to 20170404-5000-build.log.gz.
6. grepped out relevant lines from the build log:
zgrep FAIL 20170404-5000-build.log.gz | grep -v 'Result: FAIL' | \
sed -e 's/^-> //' > 20170404-5000-fails.txt
7. Used a revised version of 'order-battle.pl' to record the order in
which various modules *first* appeared in the 'fails' file and the
total number of times each module was cited. Results are attached as
What is the "order of battle"? It's an approximation of the order in
which, as of today, we need to get new CPAN releases out so that
down-river distros are no longer failing due to failures in their
For example, on March 30 David Golden prepared a new version of
Sub::Uplevel -- the #1 distro in the order of battle. He released that
to CPAN on April 01. Once he released that to CPAN, a tremendous number
of downstream distros had their prerequisites satisfied and -- barring
their own configure/build/test failures -- became installable via this
perl-5.26.0-friendly cpanm. Hence, apart from the fact that in the
first round I only looked at the first 1000 entries in the input file
while in the third round I looked at the first 5000 entries, many
entries found in 20170330's file have gone away in 20170404's file and
the tip of the order of battle looks substantially different.
This approach is useful for me because I only have a laptop to work
Thank you very much.