Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
On Sun, 23 Dec 2007 13:24:30 -0600 (CST), Dave Rolsky [EMAIL PROTECTED]
said:
Sorry I didn't notice before I posted that this can be refactored into
a while loop:
while (You don't understand the output of your own test script){
Rewrite your test script;
Release;
}
If only it were that easy.
I didn't say it was easy.
[...]
If the tester were a device it shouldn't be telling the developer what
to do either, now should it?
No sir, the tester is not only a tester, he is a user too. If the
tester has something to say and writes a bug report through the bug
channels he is a normal user, is he not?
[...]
Should testers pre-install Module::Build? I don't freaking care if
they do. OTOH, if the passthrough Module::Build installer bits don't
work, that is worth fixing, and is worthy of a bug report _for
Module::Build_.
Objection! If you distribute software that can cause some sort of
problems on the target system it should be reported to you because it
is your decision to distribute it. And you should then consider
reporting it upstream or stopping using that software or whatever else
is appropriate.
OTOH, if tester configure their systems to _intentionally_ not
follow the passthrough and install Module::Build, yeah, some stuff
will just not work, and that's not my problem. If you don't want
to install the prereqs as part of testing, then don't test.
Thank you for your argument. I don't like it but that's not your
problem.
--
andreas
Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
On Mon, 24 Dec 2007 17:26:47 +, David Cantrell [EMAIL PROTECTED] said: dc Michael G Schwern wrote: [1] It can be argued that bleadperl testers should probably not email authors I tend to agree. dc I'd argue that they should, as problems found testing against bleadperl dc seem to end up being problems in the next stable release. The argument is not about the usefulness of the reports per se, just about the practice to send CPAN authors unsolicited email. dc Personally dc I'd prefer to at least have the opportunity to fix my modules before dc ordinary users (who never touch a dev perl) will ever see the problem. As author you have already the option to fetch the reports from cpantesters either by visiting the site or by using MARCEL's App::sync_cpantesters. Perhaps needs more propagation. dc Additionally, results sent to the cpan-testers list are largely dc un-monitored AFAIK - it's really just a convenient way of feeding nntp dc and the various webby tools. If by testing a module we find an dc honest-to-goodness bug in bleadperl, it's far more likely to get noticed dc and reported to p5p if the *module* author is notified cos he's the one dc who is most likely to be paying attention. This is rather an argument against sending because the author has the right to be spared from the utter nonsense[1] that happens in bleadperl and in a separate thread it has already been confirmed that this is not desireable. dc And no, p5p definitely shouldn't be fed cpan-testers failure reports dc from dev perls directly! Even ignoring the load on the perl.org mail dc server, I can bet you that most people would just procmail them to dc /dev/null because most are irrelevant to p5p - they're the same bugs in dc modules that are also caught on stable perls. You hit the nail on the head: we need better monitoring of the test reports. But this doesn't necessarily mean that we have the right to send the reports to the authors. -- andreas [1] not that it happens every day, but every now and then a patch breaks lots of modules at once.
