From owner-freebsd-hackers Wed Jan 10 23: 7:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 5E6DA37B401 for ; Wed, 10 Jan 2001 23:06:50 -0800 (PST) Received: (qmail 17577 invoked by uid 1001); 11 Jan 2001 17:06:14 +1000 X-Posted-By: GJB-Post 2.08 05-Jan-2001 (FreeBSD) X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Thu, 11 Jan 2001 17:06:14 +1000 From: Greg Black To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <20010110233907.L253@speedy.gsinet> of Wed, 10 Jan 2001 23:39:07 +0100 <200101110647.TAA32661@ducky.nz.freebsd.org> In-reply-to: <200101110647.TAA32661@ducky.nz.freebsd.org> of Thu, 11 Jan 2001 19:47:21 +1300 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "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