Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received

[Chris Dolan]

On Dec 20, 2007, at 12:19 PM, Dave Rolsky wrote:


On Wed, 19 Dec 2007, Andy Armstrong wrote:

His view: cpan-testers are incompetent, ego tripping, quasi- 
religious nuisances.


I think there's some truth to this view.

For support I submit this bug ticket - http://rt.cpan.org/Ticket/ 
Display.html?id=27208


On the other hand, that was an exception, though a really annoying  
one.


My other big annoyance with smoke testers/reporters is that a lot  
of folks simply do not respond to requests for more information.  
It's generally pretty rare that the failure report includes enough  
information for me to do anything about it, so without an engaged  
party on the other end, it really is just noise.


Interesting.  I can understand imacat's point of view, though.  If  
cpan-testers were all to install Module::Build, then nobody would be  
doing automated testing of what happens when a user lacking  
Module::Build tries to install your module.  I see that more as  
striving for good test coverage than ego-tripping.


But I can see how it could be annoying to authors too...

Chris

Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received

[David Golden]

On Dec 20, 2007 6:07 PM, Michael Peters <[EMAIL PROTECTED]> wrote:
> I for one would like the full TAP output of the tests. Not just what get's 
> sent
> to STDOUT by default. What would be ideal (and it's something that RJBS has
> poked me about before) would be to receive a TAP Archive (prove --archive) 
> that
> could get attached to the email. Of course this needs to be opt-in 
> (META.yml?).
> Then it would be pretty easy to setup an email account that is monitored by 
> some
> tool that would extract the archive and upload it to a Smolder install.

Having verbose output in smoke reports has been on my wish list for a
long time.  It sounds like it might be time to look into that,
particularly as we look towards the next generation of CPAN::Testers
and transport via http instead of email.  Then it could be available
when you need it, but it's not clogging up email boxes with huge test
output each time.

Regards,
David

Re: Proc::Fork on Windows

[Christopher H. Laco]

A. Pagaltzis wrote:
> * David Golden <[EMAIL PROTECTED]> [2007-12-19 17:30]:
>> It looks like it does (as long as you remove the "-T" from the
>> shebang in 01.real.t.
> 
> Anyone with Windows who cares to, please bang on
> http://plasmasturm.org/attic/Proc-Fork-0.5.tar.gz
> before I send it to the CPAN.
> 
> Thanks again for tracking this down, David.
> 
> Regards,

All tests pass: Strawberry Perl 5.8.8/XP

-=Chris



signature.asc
Description: OpenPGP digital signature

Re: Proc::Fork on Windows

[A. Pagaltzis]

* David Golden <[EMAIL PROTECTED]> [2007-12-19 17:30]:
> It looks like it does (as long as you remove the "-T" from the
> shebang in 01.real.t.

Anyone with Windows who cares to, please bang on
http://plasmasturm.org/attic/Proc-Fork-0.5.tar.gz
before I send it to the CPAN.

Thanks again for tracking this down, David.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Proc::Fork on Windows

[A. Pagaltzis]

* Christopher H. Laco <[EMAIL PROTECTED]> [2007-12-21 18:40]:
> All tests pass: Strawberry Perl 5.8.8/XP

Thanks Chris. On its way.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received

[Dave Rolsky]

On Thu, 20 Dec 2007, David Golden wrote:


On Dec 20, 2007 1:19 PM, Dave Rolsky <[EMAIL PROTECTED]> wrote:

It's generally
pretty rare that the failure report includes enough information for me to
do anything about it, so without an engaged party on the other end, it
really is just noise.


With CPAN::Reporter, I've been trying to add additional context
(within reason) to assist with problem diagnosis.  What kind of
information would improve the reports?  (Not to say that this obviates
the need for a responsive tester, but every little bit helps.)


Getting the full TAP as Michael P mentioned would be good.

However, usually I end up needing to investigate aspects of the testers 
platform, often by having them run snippets of Perl code from the shell, 
or asking them to try a patch. There's not much you can do to automate 
that.


As chromatic mentioned, failures often happen on platforms to which I as a 
module author don't have ready access, so I need some assistance from the 
user of that platform.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received

[Dave Rolsky]

On Thu, 20 Dec 2007, Ovid wrote:


To summarize what I think Imacat's point is:  some CPAN testers quite
deliberately have only core modules installed in order to catch issues
just like this.  As a result, anything which assumes a non-core module
(like your Makefile.PL previously assuming Module::Build was available)
is simply going to fail.


Actually, that wasn't the problem. I was using a standard "passthrough" 
Makefile.PL, which basically just tries to install Module::Build and exec 
Build.PL after doing so. It does prompt the user but it also defaults to 
"yes, install MB" so it should work in an automated environment without 
hanging.


This seemed to have some sort of weird interaction with CPANPLUS and/or 
CPANPLUS's unfortunate decision to package Module::Build. Honestly, I 
never understood what the problem was.


The real problem in that conversation was that I couldn't get a freaking 
answer to my question "don't you need Module::Build pre-installed to test 
all of CPAN?"


I didn't necessarily object to using a standard Makefile.PL (in fact, I've 
done it before at others' request, but the request _made sense_). I just 
wanted some clarification on why she was making that request.



In fact, with Module::Build, it's even more problematic than with other
modules.  I know there are many people who simply won't have anything
to do with Module::Build and won't install it.  While the specific
reasons listed in http://perlmonks.org/?node_id=458282 have gone away,
there are still other general reasons (including "religious" ones)
which keep people from adopting Module::Build or installing it.


Well, good for them, but that's going to make it pretty freaking hard to 
smoke test a lot of CPAN modules, and that's not _my_ problem. Insisting 
that no one else use Module::Build because you don't like it is exactly 
the sort of "religiousness" that Marc Lehmann was objecting to amongst 
CPAN testers.



So honestly, don't let a language barrier get in the way.  Germans can
seem incredibly rude to Americans when the speak English while we
sometimes seem incredibly obsequious due to how we approach asking
questions.  If you don't know the cultural differences shaping the
language choices, it can seem horrifying.


Sheesh, you'd think I wasn't married to a woman from Taiwan, or hadn't 
been there 5 times already.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

Re: Proc::Fork on Windows

[David Golden]

On Dec 21, 2007 12:32 PM, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> Anyone with Windows who cares to, please bang on
> http://plasmasturm.org/attic/Proc-Fork-0.5.tar.gz
> before I send it to the CPAN.

Passes on Strawberry Perl 5.10.0 beta 2 as well.

David