Date: Sun, 21 Jan 2001 18:52:02 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Doug Barton <DougB@FreeBSD.org> Cc: Neil Blakey-Milner <nbm@mithrandr.moria.org>, 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: <3A6B7622.1158FA8E@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> <3A6B3D85.9773C9ED@bellatlantic.net> <3A6B46DF.7BE84F45@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Barton wrote: > > 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 ? As far as I've watched this thread > > nobody had explained it. So could you please elaborate ? > > The fact that you do not understand, or do not accept the many salient > points that have been made in opposition to this change does not mean that > they do not exist. I'm sorry but the fact is not that I don't understand or don't accept some points, but that no technical points were ever mentioned. The discussion was very much on the emotional level, discussing the stupidity of people who schedule their cron jobs at 2am. Please do not misunderstand me: I do like conservatism and I do like the compatibility with previous releases. But sometimes these decisions mean incompatibility with the other Unix systems, so there is some sort of tradeoff. I think that I've found a reasonable solution that can let us have both sorts of compatibility at a quite good level. > > > 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. > > With changes of this magnitude we do not shoot first and ask questions I'm sorry to ask this again and again but did you look at the changes ? > later. Both the proponents and opponents of this change agreed that AT > MINIMUM there should be a command line option to enable the new behavior. I I've proposed a solution which would implement the new option without significantly disturbing the old behavior. I had it discussed in -hackers and got only positive replies. > was planning to commit Gerhard's rc patches to allow for specifying flags My patches are different from Gerhard's. And Gerhard's test have shown that these patches do not quite solve the problem with DST support. > to cron during startup today (and still may get to it later) to make > testing the change easier. Personally, I had a lot of sympathy with the > idea of the proponents making a port of the new cron, but I could live with I do not have any sympathy to this idea. It brings linuxisation with scores of similar packages with subtle differences between them, making it difficult to predict the behavior of the typical installation and to get exactly the right package needed for a particular solution. Worse yet, making these packages coexist on one machine if too often quite a bit of trouble. > the idea of a command line option, defaulting to the old behavior. I agree with an idea of a command line option (again, nobody mentioned any technical argument why breaking minor compatibility aspect with the old behavior is unacceptable, but if people want this by a however irrational reason) but I think that making the changed behavior default is better. Simply because it hurts much less people. -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?3A6B7622.1158FA8E>