The new Update Acceptance Criteria are broken

François Cami fdc-lists at fcami.net
Tue Nov 16 22:35:53 UTC 2010


On Fri, Nov 12, 2010 at 9:14 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Fri, 12 Nov 2010 14:54:28 -0500
> Simo Sorce <ssorce at 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. ;(
>
> 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


More information about the devel mailing list