I've mentioned it on the perl-qa list, so I should probabably ask you guys too.
I currently have some time to hack on testers.cpan.org. Do you guys have any ideas for new features or other improvements? TIA.
Re:Fix the sorting
petdance on 2004-03-09T15:21:52
And thanks for asking!Re:Fix the sorting
acme on 2004-03-09T15:33:13
I have a plan. Now we already know that all authors uses different and incompatible version numbering systems, so I'm going to sort upon date of upload to CPAN! This will sort it all out;-)
Could we somehow specify in some standard way what kind of configuration is important for testing?
An example (at random
A standard way to specify a string that would identify a configuration would be great. I think the best way would be through a new field of Makefile.PL/BUILD.PL, that would define a new target in the make, something like config_id.
Does it make sense? Is it Christmas already?
Re:Perl Version... and more
grantm on 2004-03-09T20:06:58
I include a test script in each distribution solely for the purpose of dumping out version numbers of the packages I depend on. For example: XML-Simple:t/0_Config.t.
Then when I get a test failure report like this, I can see at a glance the test machine has an old verson of LibXML with buggy namespace support.
Re:Perl Version... and more
mir on 2004-03-09T20:43:26
Good idea, especially as I check the version numbers during the perl Makefile.PL phase, I'll add something like this in the next release.
Thanks
Re:Perl Version... and more
sky on 2004-03-09T21:41:24
The architecture is very important, there are significant changes to perl, and all XS modules, when you compile with different options including threading and 64 bit. So it is important to show this information.Cheers
ArthurRe:Perl Version... and more
mir on 2004-03-09T22:16:27
I realize the architecture is very important... for some modules. I know that in my case it doesn't matter whether threading is on or off for example. In the end, other factors are way more important, and yet they do not appear on the main report.
Re:Perl Version... and more
sky on 2004-03-10T08:28:44
And I am saying that you are wrong when you say that architecture is unimportant for your module.Your module runs on the perl interpreter, and if two different architectures make the interpreter run totally different code, or in a totally different way, then that architecture setting is important to your module, and also, more importantly perhaps, to other people who wish to see the testers result for your module.
Cheers
ArthurRe:Perl Version... and more
mir on 2004-03-10T09:34:45
There are lots of things that are important, amongst which, for XML::Twig, the architecture is one of the least important. So having the test report only display the architecture is not as much help to users (or to me) as displaying the rest of the significant environment.
If I wanted to push the discussion further I might even go as far as to say that it would be more useful for users to see _only_ the version of Perl or of XML::Parser, rather than the architecture. But I won't
;--) In any case I am not asking to ditch the architecture in the reports, just to allow for an additional mechanism to generate something like a signature for the configuration, based on criteria defined by the author of the module. I think this would give a better service both to users and to authors.
Re:Perl Version... and more
sky on 2004-03-10T09:38:30
Can you please explain how you arrived at the conclusion that architecture is one of the least important pieces of information.Re:Perl Version... and more
mir on 2004-03-10T10:49:36
By looking at the bug reports.
And by testing, pre-release, on a bunch of combinations of architectures and versions of the various layers under the module: if it passes on Linux then it _always_ passes on Solaris and OS X, provided the rest of the environment is identical. It passed on Dec-OSF1 4.1G, whatever that is, with a configuration that was known to pass on other architectures. I had a few cases where the install wouldn't work on Windows, regardless of the rest of the configuration, but that was easily tested, and fixed.
The large majority of the problems, and the ones which quite a pain to test, come from:
- version of XML::Parser: old (but still very common) versions used to come with their own version of expat, plus the API changed a couple of times in the past 4 years (in fact the published API did not changed but the returned values did, don't get me started on that!),
- version of perl: the evolution of Perl's unicode awareness (and bugginess) makes pre-5.6.0, 5.6.*, 5.8.0 and 5.8.[1-3] behave quite differently,
- version of expat: some are completely broken (1.95.4), plus there have been the usual changes in the API, that's a major pain because it is hard to get the version number of the library at runtime (anyone knows how to do this?),
- version and availability of various utility modules (Scalar::Util doesn't come with weaken on some systems, encoding conversion is handled as best as possible, trying to use Encode, Text::Iconv, Unicode::Map8 or a regexp (which only works for certain versions of perl
:--( ... If you look at the the test reports for 3.08 you will see that it gets 1 pass and 1 fail for the same architecture (sun4-solaris, in fact it's 2 different versions of the system, 2.6 and 2.8, but it doesn't matter). The reason? Different versions of XML::Parser. But that's nowhere on the main page, nor even in the reports (it will be with the next release). I believe that this would be an information that users would find useful.
The module is pure Perl, it does not interract with the system a lot, barely forks, does not use threads, does nothing really sophisticated, so it makes sense that in the end the architecture is not the most important factor.
Is this enough information?
