Date: Mon, 22 Jan 2001 09:35:51 +1300 From: "Dan Langille" <dan@langille.org> To: Sergey Babkin <babkin@bellatlantic.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <200101212035.JAA19266@ducky.nz.freebsd.org> In-Reply-To: <3A6B3D85.9773C9ED@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Jan 2001, at 14:50, Sergey Babkin wrote: > 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 ? First, it's not "old" behaviour. It is existing behaviour. There is a difference. Because that's what was discussed and agreed to. On this list. > As far as I've watched this thread > nobody had explained it. So could you please elaborate ? Nobody explained it to your satisfaction but you still committed it? > 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). People have asked for the existing behaviour because they want it. POLA has already been explained. Other reasons have been explained. I'm assuming you read what I read. > > 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. You have pointed out the PR (24494). Does any documentation exist which describes how this change will affect existing systems? Details of the options for invoking the proposed new behaviour? Such things were marked as important during the discussions. It would be helpful to be able to read these things now that it has been commited. [before anyone suggestions, no, I'm not going to read the code to find out] -- Dan Langille pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php 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?200101212035.JAA19266>