On Wed, 2011-05-18 at 22:49 +0200, Kevin Kofler wrote: > The thing is, if we block the release for each and every known security > issue, considering the time passing between notification and public > availability of a fix, we will never be able to release anything. We have to > draw the line somewhere, and the best way to do it is to use our time-based > schedule. I think this overstates the case. The proposed criterion intentionally does not foresee blocking for 'each and every known security issue', and no-one so far has advocated doing such a thing; the idea that we should block only for particularly serious issues seems reasonably well accepted. Particularly serious issues really don't come up that often; I'm not aware of any such issue which would have resulted in any delay to the F15 Alpha, Beta or Final releases, for instance. I don't believe F15 Final (RC3) is subject to any known remote code-execution vulnerability. > We have done 15 releases successfully that way, what's the reason for > changing this approach now? As I said, the idea isn't really to change anything; the idea is to codify our current approach. As my initial mail said, we have treated security issues as blockers in the past, but with no solid base of policy to justify it, it was done on a case-by-case, ad hoc basis. The idea of the release criteria is to provide a solid base for making consistent decisions when it comes to release blockers (based as far as possible on existing practice), as opposed to the old system of trying to follow previous precedent more or less from memory, and beyond that, going with whatever felt right. I think the release criteria / release blocker system has proven itself pretty well over the last few releases. > And how can this not lead to a chain of slippage > where each slippage for a security fix causes several new security fixes to > pop up, for which we slip again, ad infinitum? In theory it could, sure. In practice I think an analysis of the frequency of remote code execution exploits would show it's not likely to happen very often, but of course it would be best to check this for sure. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
