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.
  • and CPANPLUS has an interface to the testers, http://search.cpan.org/~autrijus/CPANPLUS-0.047/lib/CPANPLUS/TesterGuide.pod, which autrijus added after I asked about it. I still point people to testers as the more tests for each platform and a wide variety of platforms would help an author more than just some random bug email from joe user no matter how detailed. Besides, making it easier for people to bitch about something in this community isn't always a smart move. And, let's not forget that people seem to filter their mail rather aggressively these days so suggesting that authors get more email might not go over very well either. If people can't be bothered to use the RT bug database to report a bug, they likely can't be bothered to write a whole email which won't get logged and tracked.

    Testers, testers, testers. Some day, it might even catch on after people have tried to reinvent something more complicated enough times.

    • Testers is only as good as the tests that the author writes. Users always seem to find an untested case though.

      As for RT, I don't expect everyone to know how to use it, and even then, the reports I get in RT have very little information, which is why I want something to collect that info automatically.
      • Well, I cant help the cases where the authors don't write tests for their modules. The interface does allow for comments and such from the users though. I don't see how what you want and what already exists is different save for the extra information collection which could be added into cpanplus and cpan.pm.

  • I think this is a jolly good idea. The amount of additional mails module authors might get is nothing compared to the amount of time that could be saved by reports that are actually useful.

    Most reports are incomplete. They usually don't contain the version of perl or the version of the modules they used, or a combination thereof. We seldom get the actual output users receive from the broken programs, nor even the code they used. Establishing these information often takes one or two additional emails to the
  • Normally you won't be able to look at the Makefile.PL or the YAML files after instalation, so this would only be useful for reporting errors found during installation - which testers and CPANPLUS does quite nicely.

    After installation all knowledge of the original package is long gone...

    • There might be other ways to do this even if the distribution is gone. Somewhere in the universe that information exist. The trick is to figure out how to get it. So it is not as simple as opening a file, but I figure there might be one or two smart people who don't give up so easily. :)

      A lot of the other features do not depend on this, however, and, again, testers and CPANPLUS are only as good as the tests, which everyone should realize are never perfect.