Skip Menu |

This queue is for tickets about the WWW-Mechanize-Plugin-Display CPAN distribution.

Report information
The Basics
Id: 27002
Status: resolved
Priority: 0/
Queue: WWW-Mechanize-Plugin-Display

People
Owner: MARKSTOS [...] cpan.org
Requestors: imacat [...] mail.imacat.idv.tw
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Allowing Automated CPANPLUS Tests
Dear Mark Stosberg, Hi. This is imacat from Taiwan. I'm currently helping as a CPAN tester, testing all the daily uploaded modules with a semi-automated process. I found that your module WWW-Mechanize-Plugin-Display-1.00 is not friendly to CPANPLUS testers, as it does not allow automated tests. It's Makefile.PL by default tries to install Module-Build and enters an infinite loop when failed, using up all the CPU and system resources of the machines of us CPAN testers, preventing us from offering valuable test reports to other CPAN authors. Please understand that, as there are 40-60 modules uploaded onto CPAN everyday, we really cannot test each module manually and have to rely on this automated testing process. Also because of the nature of the newly-uploaded modules, we cannot possibly trust them, cannot run the tests as root and hence cannot really install anything onto our system during the test process. Having a module that requires installing something onto the system or entering an infinite loop is really frustrating to us. Could you please correct this issue, by letting ExtUtils::MakeMaker handle the Makefile.PL build process? I saw that the only thing special in your Build.PL is a hook to ACTION_dist. But since ACTION_dist is something only used by the author, that is, yourself, I believe you can write a simple Makefile.PL that really use ExtUtils::MakeMaker. You may refer to mine own as a simple example: http://search.cpan.org/src/IMACAT/Locale-Maketext-Gettext-1.22/Makefile.PL If you really cannot provide a Makefile.PL really for ExtUtils::MakeMaker, could you please remove Makefile.PL, so that CPANPLUS may refer to Build.PL and use its internal Module::Build instead? Thank you very much in advance.
Subject: Allowing Automated CPANPLUS Tests
Dear Mark Stosberg, Hi. This is imacat from Taiwan. I'm currently helping as a CPAN tester, testing all the daily uploaded modules with a semi-automated process. I found that your module WWW-Mechanize-Plugin-Display-1.00 is not friendly to CPANPLUS testers, as it does not allow automated tests. It's Makefile.PL by default tries to install Module-Build and enters an infinite loop when failed, using up all the CPU and system resources of the machines of us CPAN testers, preventing us from offering valuable test reports to other CPAN authors. Please understand that, as there are 40-60 modules uploaded onto CPAN everyday, we really cannot test each module manually and have to rely on this automated testing process. Also because of the nature of the newly-uploaded modules, we cannot possibly trust them, cannot run the tests as root and hence cannot really install anything onto our system during the test process. Having a module that requires installing something onto the system or entering an infinite loop is really frustrating to us. Could you please correct this issue, by letting ExtUtils::MakeMaker handle the Makefile.PL build process? I saw that the only thing special in your Build.PL is a hook to ACTION_dist. But since ACTION_dist is something only used by the author, that is, yourself, I believe you can write a simple Makefile.PL that really use ExtUtils::MakeMaker. You may refer to mine own as a simple example: http://search.cpan.org/src/IMACAT/Locale-Maketext-Gettext-1.22/Makefile.PL If you really cannot provide a Makefile.PL really for ExtUtils::MakeMaker, could you please remove Makefile.PL, so that CPANPLUS may refer to Build.PL and use its internal Module::Build instead? Thank you very much in advance.
Subject: Allowing Automated CPANPLUS Tests
Date: Wed, 09 May 2007 00:43:25 +0800
To: bug-WWW-Mechanize-Plugin-Display [...] rt.cpan.org
From: imacat <imacat [...] mail.imacat.idv.tw>
Dear Mark Stosberg, Hi. This is imacat from Taiwan. I'm currently helping as a CPAN tester, testing all the daily uploaded modules with a semi-automated process. I found that your module WWW-Mechanize-Plugin-Display-1.00 is not friendly to CPANPLUS testers, as it does not allow automated tests. It's Makefile.PL by default tries to install Module-Build and enters an infinite loop when failed, using up all the CPU and system resources of the machines of us CPAN testers, preventing us from offering valuable test reports to other CPAN authors. Please understand that, as there are 40-60 modules uploaded onto CPAN everyday, we really cannot test each module manually and have to rely on this automated testing process. Also because of the nature of the newly-uploaded modules, we cannot possibly trust them, cannot run the tests as root and hence cannot really install anything onto our system during the test process. Having a module that requires installing something onto the system or entering an infinite loop is really frustrating to us. Could you please correct this issue, by letting ExtUtils::MakeMaker handle the Makefile.PL build process? I saw that the only thing special in your Build.PL is a hook to ACTION_dist. But since ACTION_dist is something only used by the author, that is, yourself, I believe you can write a simple Makefile.PL that really use ExtUtils::MakeMaker. You may refer to mine own as a simple example: http://search.cpan.org/src/IMACAT/Locale-Maketext-Gettext-1.22/Makefile.PL If you really cannot provide a Makefile.PL really for ExtUtils::MakeMaker, could you please remove Makefile.PL, so that CPANPLUS may refer to Build.PL and use its internal Module::Build instead? Thank you very much in advance. -- Best regards, imacat ^_*' <imacat@mail.imacat.idv.tw> PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt <<Woman's Voice>> News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug
This was fixed in the 1.01 release.