On Wednesday 03 September 2008 00.16.48 Andrew Moore wrote:
> If the smoke testers and CPAN::Reporter and the like didn't send the
> reports directly to module authors, but instead they went through
> something that processed them centrally, then there could be some more
> control placed on the mails that go to the authors, so the first part
> of the plan that I'm envisioning is to default those tools to not
> sending mails directly to module authors (or not allow it at all).
> Then, then reports only go to the cpan-testers list.

This will vary from author to author. I'm quite happy of getting failure 
reports by mail and I don't want to bother getting to a centralized location 
or having a rss feed. Centralized always sound to be like single point of 
failure. 

> * If particular authors have opted out entirely, then of course they
> could get no reports.
> * One complaint about the CPAN Testers reports is that they sometimes
> report failures for old versions of perl for which the module was
> never designed to use.
> (<http://markmail.org/message/47twvn4uvmfkhy2p>) I understand that
> module authors can specify the minimum working version in their
> modules, and that is arguably better than leaving it open to chance.
> If there has never been a passing report on any perl older than X,
> then don't send any more reports for older versions of perl. They got
> the original report about 5.6.1, they don't need one about 5.6.0.
> * If a module never has worked on some particular OS (even though the
> author has not specifically prohibited it), then don't send another
> failure for that OS. They have gotten that one, that's enough.
> * If a particular version of the module has never passed at all, don't
> send more than one report, even if it's a failure for a new OS or a
> new platform. They may don't want to know more than once that their
> new version had a fatal error that makes it fail for everyone.
> * Perhaps I really like a particular author or module. I could
> subscribe to failure reports for that one even though I'm not an
> author at all.

All this sounds like fields that should be set in the META.yml. This gives 
complete control to the authors which is the right place I believe.

As for getting error reports for other authors modules, That's already 
available, centralized.

I don't mind people getting what they want as long as I get what I want ;)

Cheers, Nadim.

Reply via email to