>>>>> On Sun, 12 Feb 2012 17:48:54 +0000, Barbie <bar...@missbarbell.co.uk> >>>>> said:
>> A simple first-order fix would be to add something to the report emails >> indicating if a report contains an alpha dependency. Something people can >> easily filter on, either with eyeballs or robots. > Andreas' analysis is currently best placed to spot these sorts of > failing reports, as it does some very indepth analysis of reports to > spot common factors. Hence why he spotted that TM 1.005000_002 was a > factor in his post. > It may be possible for Andreas to raise an alert to an author if the > module appears to be a common factor if failing reports (regardless of > being in development or not). However, I don't know easy it would be to > automate this, or to not spam an author either. The statistical analysis done by analysis.cpantesters.org is indeed capable to spot problems of moderate complexity. Determining that TM 1.005000_002 is at fault is trivial as long as it is the only excentric distro. Chances are diminishing when there are more distros involved. And this is why I don't think I want to have it automated. > As CPAN Testers current reporting process stands, I don't think we need > to or should change it. Yes it might be an inconvience for authors, but > at least we're reporting there are problems. > In the longer term, I can look at reassigning reports to the real > failing distribution, which while confusing to a degree, would at least > mean the reports are not "poluting" distributions which are not at > fault. This might be an interesting strategy. > This is probably something we can discuss at the QA Hackathon. Yupp. -- andreas
