Re: CPAN Smoke Tests: Some platforms are meant to be broken

I suppose it would be possible to extend the CPAN META.json/META.yml file. Maybe something like "supported_platforms" and/or "unsupported_platforms". Precisely how you define a "platform" seems an awkward problem though, e.g. "Windows" versus "Windows Vista"; "Unix" versus "Linux" versus "AIX 6.1" versus "AIX 5.3" and so on. Also, Perl may be ported to new platforms after a module is released.

Comment on Re: CPAN Smoke Tests: Some platforms are meant to be broken

Replies are listed 'Best First'.
Re^2: CPAN Smoke Tests: Some platforms are meant to be broken by saintmike (Vicar) on Aug 22, 2011 at 00:02 UTC
Right, and a module might just magically work on a platform that the author never intended it to function on. Or a new platform ("QuantComp128"), might spring into existence which it might work on, although the author never heard of it. I like your idea of using "unsupported_platforms" meta info that lists platforms that the author knows the tests will fail on, but considers that normal or doesn't care. `unsupported_platforms: - Win32` [download] would then alert the smokers to mark the appropriate column in the matrix specially and refrain from sending out emails to the authors with the failed test suite results, because the results are actually considered to be a fulfilled prophecy.	[reply] [d/l]
Re^3: CPAN Smoke Tests: Some platforms are meant to be broken (code over data) by tye (Sage) on Aug 22, 2011 at 05:48 UTC
I'd prefer the use of code to determine if the platform is unsupported over trying to standardize a data format for such declarations [for example, you might declare a platform as unsupported because it lacks the quantumflux.h file or because the quantumflux.h files does not define entangle() or because there is no /proc/torhock present]. Plus, the use of code to make such determinations is already supported, it just isn't documented sufficiently conveniently. - tye	[reply]