Matt Kettler wrote: > [EMAIL PROTECTED] wrote: > >one minor complaint: effectively released on a Friday. I can't be the only > >one > >with a company policy of not changing stuff on Friday (before the weekend). > > I've got a company policy of preferring changes to be outside of work > hours, so weekends are perfect :)
At my work we also have a policy against changes before the weekend or even outside work hours. Otherwise if there were a problem the system could be down all night and not be noticed until 4am when the first high level manager arrives and finds the system broken, with no one to call for support at that time. Not good. If an update at 10am goes bad, a support call at 10:30am is much more pleasant. Changes occur during the day. If it is a typical change the user should not be able to tell. If it is more serious, such as requiring a reboot, then we want the user to verify the system after the change, and so again it happens during the day. Especially here users will be launching long running jobs and will want to be around to make use of the cpu cycles immediately after the reboot. If the machines sat idle overnight that would be wasteful. Minor changes any time. Major changes during the day. Major changes we prefer on Tuesday during the daytime hours. It avoids killing off people's weekends. Users running jobs or admins fixing problems, either way, both groups would like their weekends. It avoids the typical manic Monday issues. If something goes wrong there is a support team available to find and fix the problem in a reasonable timeframe. It is daytime when the A-team is available. So typically I make major changes Tuesday through Thursday 9 to 5. For a minor SA update I would do that anytime. If the Berkely DB libraries changed that counts as major and I would do that daytime only. If we lost the bayes engine on Friday and did not notice until Monday there would be a huge amount of untagged spam in the boxes. Bob
