On Fri, Sep 5, 2008 at 5:48 PM, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > So, whether a 2.0 design consideration or whatever, please help me get > the things I don't have to remember out of my brain and into the > computer. And maybe I'll even be able to help keep other authors from > scratching their head wondering what happened.
It's on the list. The one thing that concerns me is that some authors object to FAIL reports showing up on their search.cpan.org page and will just want them all blanked out. So my thought at the moment is that we let people "dispute" reports -- or some synonym -- and let people filter them if they don't want to see them. (Authors or end users.) > Is there a machine/configuration identifier of some sort and/or other > ways to characterize a "report source" such that once the cause of a > false report is identified every report caused by that same issue could > be automatically crossed off? Yes and no. "Modern" reports have toolchain info, environment info, etc. But to be really complete, we'd need reports to bundle up testers CPAN/CPANPLUS/CPAN::Reporter/YACSmoke/etc configuration files and so on. Benefit probably not worth the cost, hassle and privacy concerns. Most of the obvious problem "Build -j3" can probably be caught with a regex. > And now, feature creep: optional notifications of "please disregard > these reports: ... " for affected authors who have just started > ambitiously scratching their heads at the time the issue is > identified. ;-) When we have 2.0 up and running, patches will be welcome. ;-) -- David
