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.