On Wed, Aug 28, 2013 at 11:42:05AM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Dreamhost dumps Debian"):
> > To me, being redirected to stable-updates constitutes a refusal/denial by
> > the security team to use the security updates channel. Again, if it's a
> > security issue that's not important enough to be an official security
> > update, it's not important enough for me to spend time on it as a stable
> > update either. [...]> I'm afraid I don't see why you'd think that. I don't see why this would be difficult to understand. We have a process for distributing critical security updates; if the security team triages a security fix as not important enough to be sent through this process, then it's not important enough for me to work on as a maintainer either. I have no shortage of bugs to spend my time on, and while I take security bugs seriously, I'm not going to spend my time working on a security issue that our security team has by definition said is not important. > > Well, I don't think that's a very good policy. I don't see why, if the bug > > is worth fixing in a stable release for security reasons, it should go > > through the stable-updates channel instead of the security channel. [...] > As Peter Palfrader points out stable-updates allows more review, > because it doesn't suffer from the process problems caused by the need > for secrecy. stable-updates are also made in less of a hurry. Unless something has regressed in the past few years and I didn't hear about it, there is a 100% public "unembargoed" security queue that can be used for such uploads, avoiding the secrecy-related process problems. > Furthermore, from the pov of the user, stable-updates are less > disruptive. They can choose to take a point release when it comes > out, or to defer it. When they do take a point release that can be a > planned activity so that they're ready to deal with any regressions. I don't think this is incompatible with my contention that updates for security bugs should be driven by the security team. If we think a security fix should not be pushed *immediately* to users, then why should we postpone it until the next point release, instead of postponing it until they upgrade to the next stable release? Either it's an important security fix and we should push it out with a high priority, or it's not important - in which case no one should expect me to spend my time on fixing it in a stable update. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
