Re: [MacPerl] CPAN Testers

["Paul J. Schinder" <schinder@pobox.com>]

At 6:09 AM -0400 2/10/99, Arved Sandstrom wrote:

} On Tue, 9 Feb 1999, Chris Nandor wrote:
}
} > At 13.50 -0500 1999.02.09, Nathaniel Irons wrote:
} > >What range of ideal turnaround time are you envisioning?  I'm trying
}to figure
} > >out how I can fit this into my schedule.  Right now It looks like
}it'll have
} > >to be blocks of time, probably weekly.
} >
} > Monthly would be fine.  Better than what we have now, which is basically
} > nothing.  I've run out of time to carry the burden, and Paul does on
} > occasional test for MacPerl (he does tons of testing on other platforms).
}
} Hmm, now this I hadn't even thought of. Managing the flow of mail
} concerning updates on a (near)daily basis, but doing the actual testing
} every few weeks. So tentatively I'm on as a tester, I'll review the
} procedures, and do some dry runs.

A couple of the other testers batch test on other platforms.

I don't know if anyone keeps any actual counts, but the flow of mail can
vary greatly, and is rougly equivalent to a moderately busy mailing list
(more than this one, less than perl5porters).  A lot of it, the results
from other testers, you can simply discard if they're PASS.  You might want
to take note of the FAILs to see what the potential problems are.  In the
end all of the results will be on the web page, so it isn't that important
to keep them around.

}
} I have limited connect time, so what I'd probably end up doing is:
}
} (1) collate CPAN testers updates by day;
} (2) edit that as often as possible, choosing modules to test (and if there
} were multiple testers, I'be picking from a subset anyway);

Some of them, under MacPerl at least, can be disposed of immediately.  I no
longer bother with NA (not applicable) under the three Unix flavors I test
for things like Win32:: or Mac::, since it's obvious from the name.  But
it's a good idea to keep up issuing NA for modules where it's not obvious
from the name, like Tk:: on MacOS.

} (3) every so often (weekly/biweekly/monthly) doing batch testing, sending
} initial results to text i.e. no online connection.

In fact under MacOS this is probably the best way to do things, since you
can't both get and test and issue reports at the same time anyway.  In my
case under MacPerl, first I install, then I quit CPAN.pm and test, then I
start up cpantest and report.  The testing can easily be done offline, and
the reporting as a batch afterwards.

} (4) Reviewing initial results. Doing little fixes. Deciding on final batch
} to test. Go online; do actual run.

This is the time sink, and it's a good idea to not try too hard to get some
random module to work.  In the end, that's the author's job.  It is a good
idea to give the author as much as you can in the report, so I often spend
some time running the failing tests in the debugger and try to track down
the specific problem.

If the test fail because of Unixisms in the tests (Eryq's MIME-tools come
to mind, since I installed the latest last night, and the tests will need
to be ported), I'm not sure what the best thing to do is.  Since I only
test what I install, I wait until I can port the tests to issue a report.
UNKNOWN at least, maybe a FAIL with a test patch if the tests can be easily
fixed.

} (5) As part of (3) and (4) deciding what goes to Mac porters.
}
} I'll take a look at this over the next few days. But with this new thought
} in mind it appears more doable than it did before.
}
} Arved
}

-----
Paul J. Schinder
schinder@pobox.com

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch