Date: Fri, 05 Jan 2001 14:45:36 -0800 From: Doug Barton <DougB@gorean.org> To: Gerhard Sittig <Gerhard.Sittig@gmx.net> Cc: freebsd-hackers@FreeBSD.org Subject: Re: OT: silence as an answer? (was: how to test out cron.c changes?) Message-ID: <3A564E90.A49E1BE1@gorean.org> 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> <20010102125247.U253@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
Gerhard Sittig wrote: > > [ this message is no personal affront against you, Doug, but an > expression of what feeling this kind of behaviour causes for > those who want to share and find themselves ignored ] Actually, I wouldn't care if it were, but thanks for the clarification. FYI, you will get a faster response if you cc: the person who wrote you. I'm currently behind on list mail. > On Mon, Jan 01, 2001 at 18:06 -0800, Doug Barton wrote: > > Gerhard Sittig wrote: > > > > > > [ ... reminder after two weeks of silence ... ] > > > > Two weeks of silence is generally enough to let you know that > > no one is interested in this modification. If someone was, > > they'd generally have said something by now. > > Well, I don't come to the same conclusion here as you do and I'm > not so sure about it as you are. :) Silence as I see it is just > a sign for "nobody answered", without a reason to see why. Sometimes that's true. I think that my point could have been better stated as, "No one was excited enough about your proposal to take further action on it." This may be because no one wants it, or it may be because no one has had time to deal with it... or lots of other reasons. The fact is however, that things that people really ARE interested in get done. So, silence can be, and usually is rejection, even if that's not really the answer you wanted. > BTW is rejection much more the kind of reaction I had expected in > the case you describe (nobody wants it). This would have been at > least *some* reaction. The problem is that no one person can state conclusively that the project doesn't want something. One person CAN step in and make something happen, so acceptance is easy, whereas rejection is almost always a case of slow death by apathy. > Getting ignored is definitely a fine way > of discouraging future contributions. You may find this hard to believe, but I sympathize with your plight. I was there for years. That's why I tend to make the kinds of replies I did in this case so that at least the person will have some assurance that their suggestion was seen, and considered. > Some "we don't like the > approach, since ..." or a simple "Nope" or even a serious > "PLONK!" would have been great and as much appreciated as an > "yes, we like it"! It had saved time and work for _everyone_ > involved (me as being the originator as well as those I had to > annoy repeatedly when they could have stopped me right in the > beginning). As above, this just doesn't happen very often, unless it's a truly horrible idea. This is the nature of working on this kind of project. You will simply have to develop a thicker skin if you are going to survive in this environment. > > Speaking only for myself, I don't think your proposed changes > > are a good idea, which is why I refrained from offering any > > suggestions on how you can test them. You stated in another post that you wished I had elaborated more. I was in a hurry when I wrote that post, so here are more details. While this is, as you say, "an eternal problem," it is not a problem entirely without remedy. The proper solution is simply to avoid scheduling mission/time critical events during the DST change period for your time zone. Without improperly revealing sources, I can say that I did a lot of research on this topic in a past life, and it is by no means clear that your proposed solution is the best one. Consider the following. We are in the spring and DST is "springing forward" at 2am. We have a job scheduled at 2:15 that takes one hour to run. There is another job scheduled at 3:20 that ABSOLUTELY POSITIVELY cannot run unless the first job finishes. Aside from the fact that this is bad design, how should cron handle this situation? You can (and probably should) respond that this is not cron's responsibility, and come up with all kinds of ways to ameliorate this situation. My response will then be that if you can "fix" this situation without "fixing" cron, then cron doesn't really need to be "fixed." With very little imagination you could easily come up with other situations where your proposed changes will cause more harm than good. On the other hand, the "damage" that cron is doing in these situations can easily be repaired by proper system design. Therefore your changes should not be incorporated. Doug 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?3A564E90.A49E1BE1>