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/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature