Date: Thu, 11 Jan 2001 17:06:14 +1000 From: Greg Black <gjb@gbch.net> To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <nospam-3a5d5b66040447e@maxim.gbch.net> In-Reply-To: <200101110647.TAA32661@ducky.nz.freebsd.org> of Thu, 11 Jan 2001 19:47:21 %2B1300 References: <20010110233907.L253@speedy.gsinet> of Wed, 10 Jan 2001 23:39:07 %2B0100 <200101110647.TAA32661@ducky.nz.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?nospam-3a5d5b66040447e>