On 30 Jan 2011, at 08:17, Dennis Plöger wrote: > Hi! > > I think, we should talk about, what updates we install when. > > In my experience, a fast "bleeding edge" update process can lead to problems. > I would recommend the following: > > * High-Priority Packages (everything, that's futile to our services like > Apache, mysql and stuff): Wait two weeks after publication, then install > * Middle priority (everything system related, that's not public): three weeks > * Low priority (everything else) four weeks > > What do you say? > I don't think you mean "futile", maybe "crucial". :-) I'm ok with your timings, except if the update corrects something that specifically affects us. E.g. the recent PHP update to correct the floating point bug[1][2]. For updates like that one, a couple of days and a search to confirm no issues with the update should be sufficient. Can we adjust the verbosity or the timing of the emails being sent by some of the scheduled processes? I prefer not to receive "information" emails from the server, just "alerts" where some action is required. I think its counter-productive to send emails at such a frequency where the default action is to ignore them. When an important message comes along, it could get missed. I'd put "apt checker", the rootkit hunter weekly db update into the information category. If we are going to delay updates a couple of weeks, "application out of date" warnings in the rootkit hunter's daily report are information. Just getting those once a week would be preferable. And can we push forward the time that the tasks run to about 7am UTC (or at least the time that the emails get sent). - Chris [1] the php installed doesn't suffer the problem - its too old! [2] it might be sensible to update php to 5.3.x latest, 5.3 for the improved garbage collection and latest as all the others have the floating point issue.