Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
# from Andy Lester # on Monday 28 January 2008 23:37: On Jan 29, 2008, at 12:58 AM, Eric Wilhelm wrote: The results are there for everybody to see. I mean in my inbox. Hmm, yeah. That sort of ties-in to the whole thing where cpantesters has implemented web services over SMTP. So, you're probably getting mail straight from the tester rather than e.g. the web server checking your preferences after receiving the POST and before sending you mail, eh? I imagine some patches to CPANPLUS, Test::Reporter, and a wee bit of CGI could clear that up. Maybe then we could even test on windows. --Eric -- We who cut mere stones must always be envisioning cathedrals. --Quarry worker's creed --- http://scratchcomputing.com ---
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Jan 29, 2008 3:16 AM, Eric Wilhelm [EMAIL PROTECTED] wrote: Hmm, yeah. That sort of ties-in to the whole thing where cpantesters has implemented web services over SMTP. So, you're probably getting mail straight from the tester rather than e.g. the web server checking your preferences after receiving the POST and before sending you mail, eh? I imagine some patches to CPANPLUS, Test::Reporter, and a wee bit of CGI could clear that up. Maybe then we could even test on windows. The recent CPAN::Reporter release supports a 'cc_skipfile' to flag authors that shouldn't be copied on results. The problem, of course, is that we still leave that up to individual testers. I had suggested on cpan-testers-discuss that we stick a public skipfile in a repository somewhere (e.g. Alias' open repository) and let high-volume testers synchronize on that. But that's very kludgy. Frankly, it's all going to be bad hacks until CPAN Testers 2.0. For authors who don't want to be bothered, I'd suggest the easiest thing is just to filter mail as it comes in. David
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Jan 29, 2008, at 10:10 AM, Philippe Bruhat (BooK) wrote: Maybe the most practical option is still the global skip file mentioned by David Golden. Uninterested people would get a single unsollicited email, and would need to opt-out once only. Except that the global skip file would need to apply to individual bots, not the entire cpan-testers architecture. Again, I have no problem with human reports. It's the bots I mind. I also expect that at some point there might be a bot that I WOULD want to sign up for. I see it sort of like a robots.txt, where you're able to set different rules for different clients. # CPAN tester bot info file v0.1 humans: report-by: SMTP foobot: report-by: none barbot: report-by: Mechanism-name or whatever. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Tue, Jan 29, 2008 at 09:50:21AM -0600, Andy Lester wrote: Again, I ask: I would like bot notification to be opt-in only. I guess other are like me, and are too lazy to opt-in, and like to get the occasional FAIL. Of course, I do not have that many modules, so they don't come back to haunt me too often. Opt-in or opt-out are going to be a pain anyway, if we have to opt (in or out) individually with each and every tester. Maybe the most practical option is still the global skip file mentioned by David Golden. Uninterested people would get a single unsollicited email, and would need to opt-out once only. -- Philippe Bruhat (BooK) Blood is thicker than water... so beware of thick relatives. (Moral from Groo The Wanderer #18 (Epic))
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Jan 29, 2008 10:50 AM, Andy Lester [EMAIL PROTECTED] wrote: When a bot complains to me that some arbitrary ancient module has long since been abandoned, doesn't work under 5.6.1, it's noise regardless of delivery format. It is unsolicited noise. Just delete it and other people like these messages are comments heard from commercial spammers, no? It is spam -- in a sense. It's generally unsolicited. It's historical tradition to cc authors -- which is why I want to move away from email and let notification be an author's choice from a central source. Again, I ask: I would like bot notification to be opt-in only. You mean rather than a skipfile, have an opt-in file? I think that's a good suggestion. I could add that to CPAN::Reporter fairly quickly, but someone will have to go upgrade CPANPLUS or CPAN::YACSmoke and then we have to get all the automated test smokers to upgrade. David
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Tue, Jan 29, 2008 at 11:47:48AM -0500, David Golden wrote: You mean rather than a skipfile, have an opt-in file? I think that's a good suggestion. I could add that to CPAN::Reporter fairly quickly, but someone will have to go upgrade CPANPLUS or CPAN::YACSmoke and then we have to get all the automated test smokers to upgrade. You mean there isn't a backdoor in the smokers code to allow it to upgrade itself when it detects that it is smoking a newer version of itself? :-) Nicholas Clark
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Jan 29, 2008, at 10:47 AM, David Golden wrote: It is spam -- in a sense. It's generally unsolicited. It's historical tradition to cc authors -- which is why I want to move away from email and let notification be an author's choice from a central source. Yes, absolutely. Then I don't rely on someone saying Yes, report this to the author as well when he reports the problem. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Tue, Jan 29, 2008 at 10:14:08AM -0600, Andy Lester wrote: On Jan 29, 2008, at 10:10 AM, Philippe Bruhat (BooK) wrote: Maybe the most practical option is still the global skip file mentioned by David Golden. Uninterested people would get a single unsollicited email, and would need to opt-out once only. Except that the global skip file would need to apply to individual bots, not the entire cpan-testers architecture. Again, I have no problem with human reports. It's the bots I mind. I also expect that at some point there might be a bot that I WOULD want to sign up for. I see it sort of like a robots.txt, where you're able to set different rules for different clients. Also, I didn't think about it, but that information could be stored in the distribution's META.yml, so it doesn't need to be global, but can be fine-tuned for each distribution. -- Philippe Bruhat (BooK) No one profits at the death of another (except for the mortician). (Moral from Groo The Wanderer #7 (Epic))
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Jan 29, 2008 11:53 AM, Nicholas Clark [EMAIL PROTECTED] wrote: You mean there isn't a backdoor in the smokers code to allow it to upgrade itself when it detects that it is smoking a newer version of itself? :-) Don't tempt me. ;-) Of course, the CPAN::Reporter test suite has become a lengthy beast -- so I wouldn't inflict that on anyone. People need to ask for that kind of pain themselves. David
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
Hmm, yeah. That sort of ties-in to the whole thing where cpantesters has implemented web services over SMTP. So, you're probably getting mail straight from the tester rather than e.g. the web server checking your preferences after receiving the POST and before sending you mail, There's that, but I don't mind SMTP from real people. If a real person has a real problem installing a module he's really going to use, that's great. I will usually reply directly to help the person out, and modify my module appropriately. When a bot complains to me that some arbitrary ancient module has long since been abandoned, doesn't work under 5.6.1, it's noise regardless of delivery format. It is unsolicited noise. Just delete it and other people like these messages are comments heard from commercial spammers, no? Here's an analogue. How about if I start up a bot where I email all the owners of every module if their modules don't run under taint mode? Whether or not you see the validity in it, please consider my point of view on this. Again, I ask: I would like bot notification to be opt-in only. Thanks, xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
On Jan 29, 2008, at 11:32 AM, Jonathan Rockway wrote: To be honest, it's usually humans that provide the least useful reports. The bots do a much better job. If they're using CPAN::Reporter, then it's all the same. Bots do not report actual use cases. They report imagined, speculative use cases. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
Andy Lester [EMAIL PROTECTED] writes: On Jan 29, 2008, at 11:32 AM, Jonathan Rockway wrote: To be honest, it's usually humans that provide the least useful reports. The bots do a much better job. If they're using CPAN::Reporter, then it's all the same. Humans include a lot of extra junk, and they've usually misconfigured their machines. (I force-installed your dependencies but now your module IS BORKEN!!!11 Yes, I've gotten that a number of times.) Bots do not report actual use cases. They report imagined, speculative use cases. Like whether or not cpan -i Your::Module works on a clean install? Yeah, that sure is a imagined use case. Regards, Jonathan Rockway
Re: FAIL Test-Pod-Coverage-1.08 i386-freebsd 6.1-release
Andy Lester [EMAIL PROTECTED] writes: On Jan 29, 2008, at 10:10 AM, Philippe Bruhat (BooK) wrote: Maybe the most practical option is still the global skip file mentioned by David Golden. Uninterested people would get a single unsollicited email, and would need to opt-out once only. Except that the global skip file would need to apply to individual bots, not the entire cpan-testers architecture. Again, I have no problem with human reports. It's the bots I mind. To be honest, it's usually humans that provide the least useful reports. The bots do a much better job. I'm all for the robots.txt sort of thing, though. I would like to get every FAIL mailed to me without having to subscribe to the cpan-testers mailing list. A frequent annoyance is seeing the IRC bot announce a failure but having to wait an hour for the nntp.perl.org archive to catch up before I can see what the problem is and start working on a fix. (It would be nice if the main cpantesters site updated faster also, but I'm fine with just email.) Regards, Jonathan Rockway
Re: XS wrapper around system - how to test the wrapper but not the system?
On Jan 28, 2008 6:34 PM, Paul LeoNerd Evans [EMAIL PROTECTED] wrote: I'm finding it difficult to come up with a good testing strategy for an XS module that's just a thin wrapper around an OS call, without effectively also testing that function itself. Since its behaviour has minor variations from system to system, writing a test script that can cope is getting hard. The code is the 0.08 developer releases of Socket::GetAddrInfo; If you *only* test the wrapper and not the OS call at all, then people who see all the tests passing will mistakenly assume that they now have a working way to get socket address info, even though that's still unknown. It would be best to test both, and decouple them so as a developer receiving FAIL reports (or a user running tests) you can tell the difference between the two. -Ken
