On Fri, Nov 12, 2010 at 9:14 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Fri, 12 Nov 2010 14:54:28 -0500
Simo Sorce <ssorce(a)redhat.com> wrote:
> Adam why should security updates wait at all ?
> Do you fear some packager will flag as security updates that are not ?
> Surely we can deal with such maintainer if that happens...
No. The issue is that in the past sometimes security updates have been
rushed out with no testing and broken things badly. ;(
For some small number of examples (yes, anyone is welcome to please add
others you have run into to the page).
I know of at least dbus, bind, nss and a few others that were security
updates and pushe out with no testing and turned out to break things.
Perhaps security updates could have a smaller timeout?
This reminds me of the excellent "Timing the application of security
patches for optimal uptime" paper:
Maybe a smaller timeout would do, yet I don't think that we could use
a small enough (security-wise) timeout and still be safe from awful
Or a security group that tests them ?
People can't be expected to be knowledgeable or interested in all
packages that would need timely security testing.
In other words, telling all people in a group that an updated package
they don't care about is available would only add noise, while telling
relevant testers packages they care about are available may speed up
For some reason, this reminds of RHN which sends emails only if
updates for the *installed* (relevant) packages are available.
We could create a subgroup of proventesters willing to enter
information about packages they know enough for them to test in a
timely manner. Or we could extend smolt to automate that task
(on-demand, of course). After all, we all tend to use what we install.