Michael G Schwern [EMAIL PROTECTED] wrote:
These TAP extension proposals and designs for parsers and questions
for details about the TAP grammar... they should all go into the Wiki.
But the Perl QA Wiki sucks. Its slow. Its spammed. UseModWiki
sucks. And I don't have the time to maintain
Michael G Schwern [EMAIL PROTECTED] wrote:
On 7/5/06, Tyler MacDonald [EMAIL PROTECTED] wrote:
I'd be happy to. yi.org is already running a few mediawikis, as well as
cpants.perl.org. Let me know and I'll get it set up.
You win! Set it up. Let us know when its online. We'll worry about
Michael G Schwern [EMAIL PROTECTED] wrote:
You win! Set it up. Let us know when its online. We'll worry about
getting a proper domain/uri for it later.
Done! http://qa.yi.org/
Thanks!
Could you switch that to perl-qa.yi.org? Just to make it clear this
isn't yi.org's QA
Michael G Schwern [EMAIL PROTECTED] wrote:
Thanks to Tyler MacDonald and yi.org we now have a brand spanking new
wiki! http://perl-qa.yi.org/ is its location, we'll worry about
getting more official domains later.
Since I set up my own server for (then nx, now yi).org 8 years ago
Ovid [EMAIL PROTECTED] wrote:
Tracking the results in an object is a better choice than scraping from
a print buffer. One of the frustrating issues with Perl's testing
tools is the limited flexibility we have due to reading the output from
STDOUT.
I like that aspect about TAP... it's
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
OTOH, who still runs pre-5.8.x code deserves what they get.
There are horrible bugs in older Perls, and I don't know why people
still
insist using insecure, buggy and feature-lacking code like 5.6. or even
gasp 5.004. Just think Unicode
I just got some cpan testers reports on a new module, CGI::JSONRPC. 1 pass,
2 failures. One of the failures seems to be my fault, but the other one
seems really odd:
http://www.nntp.perl.org/group/perl.cpan.testers/298838
The odd part is here:
[ERROR] [Wed Mar 15 10:06:14 2006] MAKE TEST
Geoffrey Young [EMAIL PROTECTED] wrote:
I was suggesting the functionality be added to Test::More as compile_ok(),
rather than runperl() in some separate CPAN module, as it seems to closely
parallel use_ok() for modules and would be rather useful on a larger scale.
I agree, a well
Steve Peters [EMAIL PROTECTED] wrote:
/eg scripts are a nice hands-on way of finding out how a module works
in real life.
No distribution should be without one!
Unless, of course, it has an examples/ directory, which would cause the
kwalitee test to fail. ;) I do think its a good
Tels [EMAIL PROTECTED] wrote:
And packages without any actual packages, like wikimedia-graph.
But I am not sure if the agreed-on last suggestions were even implemented,
or anything else done: http://cpants.dev.zsi.at/ was last updated
2005-12-05, e.g. over three months ago :(
David Golden [EMAIL PROTECTED] wrote:
So back at the beginning of February, there was some email traffic about
how ActiveState's automated PPM build system was using an outdated
version of Scalar-List-Utils, which was causing a cascading prerequisite
failure for many distributions.
Has
Matisse Enzer [EMAIL PROTECTED] wrote:
Jeff I think that is a good theory - I mean, it is a testable theory.
I hope it is true, but I am not sure. I suggest you interview a few
IT managers - come up with a list of 6 questions and ask them to
answer in email - I can introduce you to a
Hello Matisse,
I like these two ideas:
Matisse Enzer [EMAIL PROTECTED] wrote:
2) Put the CPAN .tar.gz files in a local CPAN repository and use
CPAN::Site to install - that way we *only* get the versions in
our local CPAN repository and dependencies are managed by the
I've been thinking about automated testing again. I know this is a
bad habit and I should stop it and just get on with my work, but here's
where I'm at:
Sometimes it's beneficial for an automated tester to install
additional packages (in software I'm releasing, Test::CPANpm and
Adam Kennedy [EMAIL PROTECTED] wrote:
So while we are on the subject of META.yml, I think the dynamic_config
approach is horrible, because it defaults to an efficient error case and
relies on the author to fix the error, rather than defaulting to the
inefficient correct case, and giving the
Adam Kennedy [EMAIL PROTECTED] wrote:
Firstly is that it might turn an otherwise normal result into something
else, with no clear rule. It makes a judgement call that some level of
testing is good or bad, which isn't really the place of an installer to
call.
The reason Kwalitee has
Adam Kennedy [EMAIL PROTECTED] wrote:
I'd still like such a thing to be visible in some way. Of course
you're going to happily skip tests that require a database if you don't
have DBI_DSN set.
Not necesarily... it all depends on how important it is to you. I see
some potential cases
Adam,
I have one more edgey case I'd like to see on this list:
13. Tests exist, but fail to be executed.
There is tests, but the tests themselves aren't failing.
It's the build-process that is failing.
14. Tests run, and some/all tests fail.
The normal FAIL case due
Adam Kennedy [EMAIL PROTECTED] wrote:
Write this up. Then exhaustively test it on every single Perl platform
(50ish?) and every Perl version back to 5.004, including a random
collection similarly weird combinations (5.004 VMS, that 5.6.0 from
RedHat 7, 5.6.1 on Windows 95).
I let
Steffen Mueller [EMAIL PROTECTED] wrote:
And now that I think about it, I'm not so convinced about that whole
concenience for the end user nonsense. If they're mucking about
installing perl modules from the CPAN packages by themself, they're
probably developers that need some extra time
Barbie [EMAIL PROTECTED] wrote:
I'm one of the maintainers/developers for CPAN::YACSmoke. I was
intrigued by your post about adding a Packager plugin to it. However,
I'm unclear as to what purpose it would serve. CPAN::YACSmoke is purely
about reporting on test results. CPANPLUS does the
Gabor Szabo [EMAIL PROTECTED] wrote:
You simple cannot guess what libraries/compiler/system/kernel the user
has installed, unless you know the distribution and version *and* require
that the user never updates anything.
I think I agree. That's what I would like to see solved. If I stick
On several of my modules, the search.cpan.org page shows test
passes/failures, whereas when I follow the link to see the actual list,
there are no tests reported.
eg: http://search.cpan.org/~CRAKRJACK/Class-Driver-0.004/
Usually this clears up in about a day, but in some cases it's been
Chris Dolan [EMAIL PROTECTED] wrote:
* for windows only
* only includes Foo-Bar, but not it's dependecies
It will auto-install dependencies just like CPAN, I believe. And,
yes, it's currently Windows-only. Didn't you offer bonus points for
Windows??
Um, no it isn't!
Jeffrey Thalhammer [EMAIL PROTECTED] wrote:
Randy Kobes distributes Win32 PPMs for some of the
modules that ActiveState doesn't provide. It is not
entirely automated, so the latest code isn't always
available. But Randy is very helpful if there's
anything you want to see.
Gabor Szabo [EMAIL PROTECTED] wrote:
I have just moved to Ubuntu and thought I will try to rely on apt-get
to install my Perl modules. Quckly I hit a wall and could not install some
of the basic modules. I did not have the time to investigate and check
if I made a mistake or if there is a .deb
Jeffrey Thalhammer [EMAIL PROTECTED] wrote:
* Should a test script have a shebang? What should it
be? Any flags on that?
It's not at all neccessary, but IMHO it is good form; it's a surefire way
for anything else (HTTP server, IDEs, etc) to figure out that you're
actually a perl script and do
Hello,
Is there any way to tell if my package is being tested automatically
under CPAN::Testers? Here's the situation:
I have a DBI extension (DBIx::Transaction) whose unit tests
currently depend on a valid DSN being available. SQLite makes a good testbed
for mock databases, so
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
For CPAN smokers based on CPAN::YACSmoke, the answer is: test the
presence of the AUTOMATED_TESTING environment variable. See also
the following page for more details:
http://search.cpan.org/dist/CPAN-YACSmoke/lib/CPAN/YACSmoke/FAQ.pod
29 matches
Mail list logo
