Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I should probably add email validation to CPAN::Reporter. This wouldn't catch "nospam@dontspamme.com" but would at least ensure a valid RFC format. Do people think that's useful or is this pointless?

    If pointless, what would we need to have it be relevant? Send a test message and see if the MX accepts it? That's going to be a pain to do reliably because of firewalls. Just check that there is an MX for the given domain? Is that enough?

    And which CPAN modules are back-compatible enough to add as a pre

    • Let people register as testers by confirming an email address that is used as their "from." Then it can be made clear which reports come from registered testers. More data could be collected, if they were willing: contact prefs (STFU or "happy to help"), location, platforms tested, etc.
      --
      rjbs
    • Unfortunately, hlagh@hlagh and hlagh@hlagh.hlagh are perfectly legal according to the relevant RFCs. Some form of registration system would work to fix this, and would also presumably be part of the shiny HTTP future and so reduce the mail load on perl.org. But it would also form a barrier to entry for those who just submit test results for the small number of modules they need for their own use
    • As Dave mentions, whether an address is RFC compliant doesn't guarantee a real address. Whether the domain resolves to an MX record again doesn't mean the address exists. The only way is to send a mail to the user requesting a response to verify themselves, such as happens with several mailing lists. With so many people getting involved with testing now and the value of ensuring authors can contact testers should they need clarification of any reports, then registration is a logic next step.

      With the HTTP i

  • As always, you and the rest of the testing crew have my gratitude.
    --
    rjbs
  • Since CPAN::Reporter I have toyed with the idea of becoming a tester… however, all I have to test on is my dev machine, a bog-standard Slackware 12.0 machine, ie. an unthreaded 5.8.8 on 32-bit x86 Linux, with my particular mix of required modules installed among the system perl. I wouldn’t set up any sort of controlled environment. I wouldn’t be going out of my way to generate test reports either – just send the occasional one when I install something.

    And I have to wonder if that

    • Occasionally, for whatever reason some distributions do miss out. Usually because they require libraries that the testers don't have installed, or they filter out some distributions due to problems with test them (e.g. I couldn't test Apache modules on Win32). So even if you do have a common setup, it is still possible for you to find a failure that hasn't been found by other testers. Whether you only submit 1 report a month or hundreds, it all helps :)

      Also because you don't have a minimal "fresh" installa