On Fri, Nov 12, 2010 at 9:14 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Fri, 12 Nov 2010 14:54:28 -0500 > Simo Sorce <ssorce@xxxxxxxxxx> 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. ;( > > See http://fedoraproject.org/wiki/Updates_Lessons > 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: http://www.homeport.org/~adam/time-to-patch-usenix-lisa02.pdf 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 regressions. > 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 things. 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. FranÃois -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
