I don't think this is documented anywhere, so let me blog about it before I forget it. Install the module CPANDB. See if it works by running one sample program, maybe:
print Dump [CPANDB::Distribution->select
("order by volatility desc limit 1")];
It may take a while but you will get something like this:
The kick now is that after such a command you have the current database on your local disk. I found it in my homedirectory under
Now you can access it directly and find, e.g., the modules depending on
% sqlite3 ~/.perl/ORLite-Mirror/CPANDB.sqlite
SQLite version 3.7.4
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select distribution from requires where module='Catalyst::Devel';
And what is most amazing about it? That 186 or 46% are either resolved
or patched. That's a wonderful success rate.
If you have a login on rt.cpan.org you can issue this query to see the
actual 401 tickets.
Very nice graphics and ad-hoc statistics are then provided by RT when
you look at the bottom of the page. I've never noticed that RT footer
under the result of a query before.
For example I can create a bar chart by CreatedMonthly that shows me
when the rally started: 65% of the tickets were created from August
to December. That's because on the first days of August was the relaunch
of http://analysis.cpantesters.org/ after a few months break due to the
cpantesters 2.0 launch. Analysis is the real work horse that drives me
in this game. It's kind of playing solitaire with bugs. Analysis
provides the deck: cards of many different shapes and colors, my job is
to read them and find the ones that can be resolved quickly.
A never ending deck it seems. In the last four years we had over 3400
uploads to CPAN that have both passing and failing tests. Enough material for more players. Feel yourself invited.
The total number of my posts to rt.cpan.org over the years approaches 1500 tickets. 840 of them are
resolved. That's a lot and then again it's a lot that remains
unresolved. The first thing you have to learn if you're about to
follow my footsteps: don't expect too much and be patient. Today I can
enjoy mails about resolved tickets I have opened years ago and hardly
can remember. They are the final intrinsic reward for the hours spent in
the RT ticket game.
Analysis has changed the game drastically though. In the old times it
was a purely random process when I was hitting a distribution with a
failing test. Only when some other channels brought my attention to a
distro and a test of that distro failed then I had a case for a
potential bug report. Analysis now brings the distros to my (and your;) attention
nearly instantly. As soon as it has at least three PASS and three FAIL
reports it gets listed in analysis. This may be on the same day as the release. I
usually wait until three whole days have passed before I allow myself
to report. I think this is a polite grace period that gives the authors a break.
If a bug report arrives as quickly as 72 hours after the release many
authors are still familiar with the process of
releasing and immediately make a new release. That's so
fascinating. Getting 46% of the tickets resolved within a few months was
not a goal you hoped to reach in the old days. The standard seems to be
shifting. Thank you, all.
PS: if you know of other software QA projects using multivariate
statistics to identify potential causal relations, please post them
here. I'm eager to learn about other approaches.
Every so often you may have found yourself puzzled by the results the cpantesters provided, wondering which reasons may stand behind the fails or passes.
So you click on one of the FAIL reports and it doesn't reveal anything useful to you?
Chances are that if the reports contain some common pattern the new analysis site will point it out to you. Analysis uses some well known basic statistical tools that estimate the influence of independent variables on the result of the test runs.
During the last two months I wrote over two hundred RT tickets based on the findings (see also my use.perl.org posting). Among my first favorites were FAILs that happen only when
uselongdouble is defined, like #51196. There are plenty of similar ones. Another case where the tables provided a guaranteed quick understanding of the problem was when an upgraded prerequisite broke the distro, like #52889. See how the table at analysis marks all Test::Builder versions above 0.84 as red. You can skip reading reports and go directly to the Changes file of Test::Builder to see what they changed around 0.84.
What I'd love to see is that cpantesters got some inspiration from reading these tables. When I see a distribution with only a dozen test results and plenty of strong correlations I try to create reports that add new flavors to the existing set. After a few hours or days I visit the cases again and sometimes the number of strong correlations has dropped and a clearer picture evolves where the hot spot is.
Another use of the site is to identify broken cpantesters setups.
Another one to discover bugs in bleadperl, as in #50939.
I'm sure you'll find your own entertaining bits in it. Enjoy!