>>>>> On Sat, 29 Mar 2008 04:53:27 -0400, "David Golden" <[EMAIL PROTECTED]> >>>>> said:
> I don't really see why the extra logic is necessary. Module authors > are trying to write something that people can use. CPAN Testers is > only an approximation of that use. I'd rather err on the side of > tossing reports I'm going beyond that: toss the entire _make_ unless they say "allow_future_timestamps". Then CPAN::Reporter could refuse to send reports when they actually do set "allow_future_timestamp". > that might be valid rather than report a failure that > is only a transitory condition. Admittedly this is only third hand experience but somebody once spent several days of debugging until they found out that the tester did not set the time correctly on the tested device. Transitory or not, in this case the device would have been useless for many *years*. (The case was dealing with SSL certificates) >> Then the remaining conflicts can be resolved between users and authors >> directly and we testers stop interfering at all. And those who test >> later can test normally. Opinions? > Better might be just to scan all the files after unpacking for > anything in the future and fix the timestamp (assuming that can be > done portably). Just DWIW. And I believe this is something that only an educated human can do correctly because a perl program knows only very little about the environment it runs in, especially it is helpless in determining the real time. And not all possible issues have to do with wrong _relative_ time. Many deal with _absolute_ time. The more I talk about it the more I believe my plan as of yesterday was not too bad. -- andreas
