Karl Berry wrote in the other message: > I think mgt might be the closest to savannah-hackers and the furthest > from the public and therefore I propose that we upgrade it first. > > Also sounds good to me.
Sounds good. Will upgrade mgt first and then decide what to do next. > When would be a good time to perform this upgrade? > > I don't think it really matters, assuming downtime is basically a matter > of a reboot. (Especially for mgt.) A VM should boot very quickly. As a risk management I will coordinate with sysadmin just in case something goes really bad and it needs a rescue. I don't expect that to be needed. But just in case. > I would suggest posting a news item so users have a chance of knowing > what is going on. https://savannah.gnu.org/news/?group=administration Okay. I see that there hasn't been a news posting there since May 2012. > How long of a waiting time for major events such as this should we > have between posting a proposal for action and then performing the > action? > > Once Michael confirms, you're good :). Otherwise ... a few days > at least? I would want to do this during daylight sysadmin hours too. Same thing with the firewall rule changes too. Just in case. > Other comments? > > Do you have any sense of what breakage might ensue from the upgrade? I don't expect any breakage. But examples of past breakage would be those /etc/init.d/* scripts that I just posted about fixing because they were locally added but didn't have LSB headers. Without those the system tool 'insserv' could not determine how to make the symlinks and order the boot. Since we hit those a couple of times already there might be another VM or two with a problem like that lurking. If the machine hasn't been rebooted since those were installed then the reboot path for them won't have been tested. And we all know the truism of untested code. It is why I like to reboot first before making major changes. I already fixed mgt for these. But I can't predict any other problems beyond those similar to the past ones. I can only do my best looking at things going in and react to them as they occur. I will also look for packages that contain obsolete conffiles especially any leaving files behind in /etc/init.d since those can be troublesome due to missing LSB headers. And will look for held packages and try to understand why and to clean them up if I see them too. Plus I will look for old/new conffiles '*.dpkg-*' and '*.ucf-*' in /etc and clean those up both before to start clean so that any left are from this upgrade. And then look afterward to leave it clean for next time. But since I expect that the Savannah Hackers all do reasonable things then I don't expect any breakage. :-) Missing LSB headers in init scripts is kind'a a common gotcha that I have seen everywhere since those have newly appeared on the scene as required. Minor in the grand scheme of things. But not expecting any breakage doesn't mean there won't be any. Must plan for problems regardless. I always worry about the possibility that someone has compiled in custom Apache modules that might be disconnected by the Apache upgrade and need to be rebuilt. But so far haven't hit any. (No Rails Phusion installed that I can see for example.) > What will the new version be? The current Debian Stable "Squeeze" point release version is 6.0.7. > Is there a super-high-top-level NEWS-ish list for each Debian > release? Since the latest on the VMs is 6.0.2 it means we have missed the last five point releases and if you are interested in the changes then all of those would need to be examined. And for frontend the first two point releases as well. Remember that there isn't any change in functionality. These are all considered Debian 6.0. These are security patches for the most part. Along with other things that are considered safe but important enough to backport into the release branch. We will be picking up the last two year's of security upgrades all at once. Here are the individual release notes for the ones we will be getting. http://www.debian.org/News/2013/20130223 6.0.7 released http://www.debian.org/News/2012/20120929 6.0.6 released http://www.debian.org/News/2012/20120512 6.0.5 released http://www.debian.org/News/2012/20120128 6.0.4 released http://www.debian.org/News/2011/20111008 6.0.3 released http://www.debian.org/News/2011/20110625 6.0.2 released http://www.debian.org/News/2011/20110319 6.0.1 released Bob
