What this is aboutThe perl programming language has a huge repository of reusable code known as the CPAN. CPAN has a strong tradition of providing selftesting facilities with every software package it contains. There are dedicated serverfarms running around the clock to produce fresh test results of many different platforms in many different environments. These get delivered to the cpantesters. On this page we are watching the results of all these tests and calculate statistical regressions to help the users of CPAN spot patterns where things are starting to fail.  
Howto use  
 The main page consists of a large table of CPAN distributions that had at least 3 PASSes and at least 3 FAILs and has been uploaded within the last 16 years. This limitation is an entirely arbitrary compromise between incoming tests, number of distros with mixed results and computing power needed to calculate all the regressions. It may change any time when some of these parameters change. The list is sorted by upload date, descending. Of any distribution only the latest upload can be included in the list. If Javascript is enabled in your browser you can sort this table by clicking on the table header in the column you want to sort. These are the columns on the main page:
The distro column contains links to separate pages per distribution providing results of the regressions analyses. These are sorted by Rsquared in descending order. Rsquared is a measurement for the quality of the statistical correlation. It's always between zero and one. The higher the Rsquared the stronger the impact of the referenced variable on the outcome.  
Collection of Regressions  
Imager0.71_02 (matrix, searchtools, parsed reports, metacpan.org)

The individual CPAN distribution's page of results of the many individual regressions starts with a small listing of metadata like who the author and what the exact filename is and links to other sites dealing with CPAN. Below that a rather long list of individual results of regression calculations follows. These are sorted by their goodness of fit, i.e. the first few results are likely to be the only interesting ones. But since statistics needs to be interpreted to be useful we present them all. Every regression has a header denoting the name of the independent
variable. These names are documented in the
When you click of any such header you are taken to the page described below under Links to input data.  
Interpretation of correlations  

You can read more about statistical regression analysis but you are allowed to bypass the theory and focus on two things: the term R^{2} (pronounced R squared) is the overall measure of the goodness of fit of the estimates. It is between 0 and 1 where 1 is a good fit. The Tstat values measure each estimation if its slope differs significantly from 0. It is between −infinity and +infinity. In the detailed page of all regression tables for a particular distribution you may find a table like the one on the left. First a few notes about what you see here: The title of the table denotes the name of the variable that is inspected by this regression test, in this case qr:(Can't locate \S+pm). At the bottom you find the R² (Rsquared; R^2) described above, the N denotes the number of observations we had and the K denotes the number of lines (actual values) we see in the middle part. The middle part lists the influencing factors in this test: in the first line a constant part [0='const'], below it the actually observed strings. Each line has the Theta value that can be interpreted as the direction and slope of the influence, the StdErr that gives us a measurement of the variance, and the Tstat which provides the significance of this theta (being different from zero). We have chosen to colorcode the Theta column: negative values are reddish and positive values are greenish, signifying that positive values indicate an influence towards a PASS and negative ones to a FAIL. Both green and red are getting paler the lower the Rsquared is to indicate that interpreting values with low Rsquared should be avoided. A weak influence is only then a weak influence when the goodness of fit confirms it. Otherwise you just can't tell. Some reason makes this influence insignificant. The example regression to the left is the most trivial case:
whenever the message Can't locate Kwiki/Plugin.pm has been seen
in the test output then the test result was a FAIL. Same thing for
Spoon/Plugin.pm. The author has most probably forgotten to
declare a dependency on the two modules Usually the Can't locate \S+\.pm messages are the most reliable indicators of the real reason of a fail. Another good candidate are mod:* variables like the following:  

Here we have a case where the author seems to be using a feature of
But such mod:* correlations can be misleading and at times completely bogus when the number of test results is low and the number of releases of a represented module is relatively high. Then (and not only then) it may happen that only one tester farm has this version installed and this testers farm is broken for some reason and the real reason for the fail has nothing to do with this version of that module. This is why you're required to reproduce FAILs and PASSes on your own hardware and compare with the other correlations and draw your conclusions carefully before writing a ticket on RT.  

One annoyance of regression analysis is the fact that every calculation presented is always relative to a reference group. See for example this result: We can recognize that having installed version 0.11 of
 
Links to input data  
PodToDocBook0.7
 If you click on the header of an individual regression result you follow a link to this table. It shows a summary of the input data collected and each line in turn has a link to the original cpantester report containing the referenced value. You can choose from the dropdown menu which columns you want to have summarized. Note that you can select multiple columns in this drop down simultaneously. If Javascript is enabled in your browser you can sort this table by clicking on the table header in the column you want to sort. If you want to collect statistics you're missing here, you may want
to check out  
How can I help?Write me your bugreports at the CPANTestersParseReport Tracker. Become a CPAN tester. Provide more and diverse data. When you find a pass to fail ratio of 9:5 you should not expect too much and rather try to improve the data than draw conclusions. Be aware that the regression analysis often is exposing covariances that explain nothing. Healthy results typically appear with higher numbers of PASS and FAIL. When the column high correlations shows many different candidate fields then it is also very likely that many testers had identical configurations and the results are not really telling much. Watch your own perl installations and see where you can try to diversify the data and provide tests with them. If the data suggest that perl 5.8.4 is failing, try to find a 5.8.4 on your disk and see if you can get it working. If you find your own results in the sample try to reproduce them. Too often we have seen random test results. And try to produce the other result by variation of parameters you can influence. Anything that makes the data less uniform automatically helps the statistical methods to bring the most interesting factors to the top. And when you identify the culprit don't hesitate to report the bug to RT (or whichever bug tracking has been chosen for the distro) so that others do not waste their time with the same distro.  
Source codeThe sources of all the programs involved here are in my git repo of cpan and related tools git://repo.or.cz/andkcpantools.git . The main script is cnntpsolver.pl. It is maintaining the databases and producing regressions. The catalyst app with the name CPANBlame produces the pages. Andreas König, 20150331 