>>>>> On Sat, 25 Oct 2008 17:05:51 -0400, "David Golden" <[EMAIL PROTECTED]> >>>>> said:
> I think so. Any automation that should report a failure or abort or > whatever on "make test" will have a hard time doing so. I already > sent it in. If they choose to mark it "WONTFIX", that's up to them. Too True. >> Exactly. My suggestion for an approach would start from the other end: >> if the output resembles the new Test::Harness output, then try to rely >> on it. Otherwise let the existing code do its heuristics. > Well, it's more subtle than that, really. Since *anything* can be > printed to STDOUT by a test, I prefer to do as little text parsing as > possible. A recursive Makefile.PL requires grepping the entire output > for things resembling Test::Harness results. That's *probably* safe > with the new format, but I still tend to want to avoid searching for > magic text as much as possible. When there isn't recursive > Makefile.PL, we're pretty much guaranteed to have a valid > Test::Harness string found first when scanning lines in reverse. I should not give advice on something I haven't tried, I better trust your judgement and actually do:) >> > On the other hand, I don't really think we should be testing parrot >> > with CPAN Testers anyway, >> >> Why? > For the same reasons we don't test Perl. Here I'm tempted to disagree. I'd love to have parrot seen as one of our cats to herd, even when the cat is not interested in being herded. I think we should not give up on them, but in the end it's up to them. Why? Because parrot uses the same infrastructure as modules and so we are in a good position to provide valuable input for them. >> > so this isn't a high priority for me to fix. I'm willing to do the >> > first option I gave, above, because it's simple and should break >> > anything else. (Unless someone convinces me it's a bad idea). >> >> Probably too risky? I would not bet on it. > Sorry. I meant to say that a more limited check for recursive > Makefile.PL should *not* break anything else. It is the simplest > change to CPAN::Reporter that would fix this issue with parrot, so I'd > prefer to do the simplest possible thing instead of something more > involved with larger unknown consequences. Simply do not listen to me, I'm sure you know what's the most promising approach. -- andreas
