Date: Sun, 21 Jan 2001 14:50:29 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: Matt Dillon <dillon@earth.backplane.com>, John Gregor <johng@vieo.com>, Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.ORG, gjb@gbch.net Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <3A6B3D85.9773C9ED@bellatlantic.net> References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Neil Blakey-Milner wrote: > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > All, > > > > I've committed these changes for cron to support DST change > > to -current (see PR bin/24494 for description of my tests). > > Everyone is welcome to test them out. > > Please let me know if you encounter any problems caused by them > > (and better do that before these changes would be MFCed to -stable > > in a few weeks). > > I do believe this is premature. There really should at least be an > option for the old behaviour, and there is a good argument for making > the new behaviour optional dependent on a variable with the old Let me ask a simple question: Why ? What are the benefits of preserving the old behavior ? As far as I've watched this thread nobody had explained it. So could you please elaborate ? On the other hand I clearly see the benefits of avoiding loss or duplication of once-a-day (or even more rare) cron jobs. If some job is scheduled once a day (or even once a week or once a month) then it's probably a rather heavy job. So running two of them at once is not a good thing even if they would not mess up each other but just slow down the machine. Skipping such a job seems to me as an almost equally bad thing. (Yes, I'm speaking from my personal experience as sysadmin as well). > behaviour default. _Especially_ if you intend to MFC this, since > changing this behaviour in a minor release, without a way to have the > old behaviour, is almost certainly wrong. That's why I asked for comments. -SB 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?3A6B3D85.9773C9ED>