On 23 January 2018 at 09:56, Alceu Rodrigues de Freitas Junior via cpan-testers-discuss <cpan-testers-discuss@perl.org> wrote: >>> 6. Not every CPAN contributor writes tests that allow execution of >>> tests in parallel, or even to run in parallel with another perl >>> executing the same tests at the same time. >> >> >> This would be an interesting thing to have, but I always thought that >> the specification should go into the distribution's META.* files (wasn't >> there already a proposal?). And CPAN.pm may inject changes into the META >> information via distroprefs files (at least this is possible for >> dependency information). > > > I agree with that. A default value of "disabling" parallel tests should be > assumed if there is no information stating the contrary.
I take the opposite view, that testers should be encouraged to run tests in parallel by default, and report issues they find, knowing that this can expose false-negatives: The grounds? Sometimes this exposes some sort of design issue in the runtime code as well, where the runtime code accidentally prohibits 2 processes co-existing or causes anomalous random bugs when they do. I also partly object to data about this being stored in META.* , because that file is already grossly overloaded with concerns that aren't part of the critical install purposes of that file. ( Although this usage is decidedly more relevant than half the crap that lives in those files and randomly breaks things with Unicode nonsense ) For people who have tests that by design oppose parallel testing, they should be encouraged to provide a rules file as follows: https://metacpan.org/pod/TAP::Parser::Scheduler#Rules-data-structure in a file called "t/testrules.yml" as per https://metacpan.org/pod/release/LEONT/Test-Harness-3.39/lib/TAP/Harness.pm#new This means instead of a simple binary "no parallelism" vs "Parallelism", fine grained control of where parallellism is problematic may be employed. Then testers who wish to minimise the number of parallelism related failures can use some heuristic like: if ( $dist->release_date->year >= 2015 && Test::Harness::VERSION >= 3.31 ) { export HARNESS_OPTIONS="j10"; } But given that there is already a way for authors to handle this problem sanely for all consumers with new enough Test::Harnesses's, it seems silly to invent something else that is substantially less powerful and requires changes to all the CPAN::Meta stuff in the process, and requires sizeable changes to our tooling to pull newer versions of things to handle the new fields, etc, etc etc.
