"Dan Langille" wrote:
> On 11 Jan 2001, at 16:33, Greg Black wrote:
>
> > We'd need some guarantees that the attempt to maintain current
> > behaviour was done correctly -- i.e., without introducing bugs
> > that broke things.
>
> What sort of guarantees are acceptable?
It would need to be tested against a set of "suitable" test
crontab files across both ends of DST transitions using real
timezone files -- either by running it for several months in
-current or by dedicating a test machine that was rebooted
several times for date changes a few days before and after the
DST transitions. Faking timezone files leads to suspicions
about bugs in them. Changing the date on a running system
without rebooting leads to uncertainty about side-effects of
large date changes.
If I was doing this, I'd be looking for input with test data for
the crontab files and I'd be looking hard (in advance) at the
kinds of outcomes that would serve to validate the behaviour.
Having once written and then maintained a cron implementation
(more than 10 years ago), I do know that covering all bases is
non-trivial.
And, as I said previously, I'd want to know how the new code
coped with cron being stopped and restarted during one of the
DST transition times, as well as seeing assurances that the
legacy version would do the same thing then as it does now.
> > In the beginning, something like CRON_DST_HACK="NO" in rc.conf
> > with a comment pointing to the explanation should cover both
> > these items. If more is needed later, then it can be added.
>
> Do you mean /etc/defaults/rc.conf?
One of the ways we break the POLA is the habit of changing the
names and locations of those files. But yes -- if that's still
its name when/if this thing happens.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
