G'day brian / pqa,

brian d foy wrote:
In article <[EMAIL PROTECTED]>, Paul Fenwick
<[EMAIL PROTECTED]> wrote:

On that note, surely we could save a lot of anguish with regards to many of the CPAN tests just by making the optional ones[1] actually optional? As a completely off-the-bat suggestion that could be controlled by META.yml:

Why should I have to work to disable something I don't want and doesn't
apply to me? Why make me do something that distracts me from the real
issue of writing better modules and packaging distributions wisely?

In which case let me revise the idea. Why not have it so that you can go to extra work to enable something you DO want and which DOES apply to you? There were recently a number of short-lived tests added to CPANTS, I'd love to be able to say that I do want them run for (some of) my distributions.

Presently there seems to be a cycle of adding new tests (which I imagine takes considerable work), which is then followed by those tests being removed due to general outcry. That seems to mean that CPANTS is stuck where it is without much space to wiggle. Having even the most coarse-grained way of disabling/enabling extra tests I think has the potential to get around this.

Authors who consider Test::Pod::Coverage (or any other metric) to be harmful can switch it off, and have it disabled for ALL their modules. Authors who think their module isn't complete until it's been packaged and shipped in Debian can turn on those extra tests. Authors who want to make exception to their rules can put extra data in their META.yml. Authors who don't know about CPANTS still won't know and probably won't care.

I've only been on perl-qa for a couple of months, so maybe this discussion has already happened and I missed it. If so, let me know, and I'll go back to lurking in the corner.

Cheerio,

        Paul

--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681

Reply via email to