Application of security fixes for the kernel does not typically cause the machine to be automatically rebooted. For optimum security, we should try to ensure that all machines are rebooted into the latest installed kernel on a regular basis. It's not worth trying to figure out what kernel security fixes are important or not.

There may be some exceptions to this - for example, a virtualization container machine like VBox will typically have:
 
 - No non-sysadmin login access
 - No open ports other than ssh

And is considerably more of a nuisance to reboot, so we may want to consider not rebooting such machines except for identified critical kernel fixes.

Our record recently in having machines come up properly after a reboot is very good. Even so, reboots should typically happen during working hours at the relevant colo unless the GNOME sysadmin team has remote console/power access itself.

Possible procedure:

 - Automate collection of running kernel and latest installed kernel across all machines into a single report
 - Send a daily nag-mail if there are any systems that need reboots
 - Check-off at the monthly team meeting that the report is currently clean, and if necessary assign a volunteer to deal with scheduling reboots.

The low tech-form of this is to send per-system nag mails; I'm not quite sure how the collection of data across all systems would work, though we need similar things for a lot of montoring (e.g., disk usage). The disadvantage of per-system nag messages is that it contributes to the general white-noise that gets ignored.