From owner-freebsd-hackers Wed Jan 10 22:34:54 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 6EB8A37B401 for ; Wed, 10 Jan 2001 22:34:18 -0800 (PST) Received: (qmail 17299 invoked by uid 1001); 11 Jan 2001 16:33:57 +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 16:33:57 +1000 From: Greg Black To: Gerhard Sittig Cc: Doug Barton , freebsd-hackers@FreeBSD.org Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200011191816.KAA81473@freefall.freebsd.org> <20001119214008.Z27042@speedy.gsinet> <20001120143658.B4415@netmode.ece.ntua.gr> <20001120193326.C27042@speedy.gsinet> <20001205225656.Z27042@speedy.gsinet> <20001220211548.T253@speedy.gsinet> <3A513799.75EAB470@FreeBSD.org> <20010102133239.V253@speedy.gsinet> <20010107170840.G253@speedy.gsinet> <3A5AE490.D251F590@gorean.org> <20010110233907.L253@speedy.gsinet> In-reply-to: <20010110233907.L253@speedy.gsinet> of Wed, 10 Jan 2001 23:39:07 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gerhard Sittig wrote: > I take notice of your (and Greg Black's) reservation / being > opposed, respect it and conclude that the change will have to > - default to the current behaviour (something quite usual for > expanding changes) We'd need some guarantees that the attempt to maintain current behaviour was done correctly -- i.e., without introducing bugs that broke things. > - be well documented (something absolutely clear to all of us, > strictly speaking it's way out of imagination for us how > somebody could contribute undocumented stuff ... :) One of the things that would need to be documented is what will happen to the new algorithm in the situation where cron is stopped and re-started during one of the time periods that gets repeated. > - yet be enabled easily for those interested in the change to > work for them and free up some of their resources for more > important tasks > - maybe provide knobs (besides the on-off-switch) to customize > behaviour in a more fine grained way 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. > BTW: There's good news for those with a dislike regarding the > change: While testing I'm stuck again, so there will be some > more delay. Previously we were told that this stuff had already been tested for years under another OS and was therefore robust and reliable. Now we learn that these claims are not correct. And you wonder why people are reluctant to even consider these changes ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message