On Wed, Nov 22, 2000 at 10:02:47AM -0500, Ben Collins wrote:
> So do we want to change that to "wait for 2.2r3" just after releasing
> 2.2r2? IMO, if the securty fixes don't get it, there is no way we can
> recommend CD vendors using 2.2r2.
2.2r2 will have security problems when released. Hopefully it won't have
any known security problems. But the only thing that can be assured
is that it won't have any *fixed* security problems. Right now, what
we're distributing on CDs and what we have on the ftp site has security
problems we have fixes for.
If it's acceptable to leave 2.2r1 around with security holes that are
only fixed on security.debian.org, it's acceptable to have 2.2r2 around
with security holes that (after a few days) will have fixed versions on
security.debian.org.
If it's not acceptable to have 2.2r2 out with known security problems
we have fixes for, how can it possible be acceptable to have 2.2r1 out
with necessarily *more* security flaws?
> > Since I'm being held responsible both for the current situation and for
> > resolving it, and since no one else appears to be willing to take over
> > that responsibility, forgive me for not being overly willing to just
> > let 2.2r1 sit around for a couple of weeks, or overly interested in
> > negotiating about that timeframe.
> Part of the reason I agreed to take on organizing the info for the release
> was so that it was taken into account for the timeframe, which doesn't
> appear to be happening.
At this moment: We. Do. Not. Have. A. Stable. Distribution.
This is what we've announced. This is what the DPL asserts. This is
what's been promulgated on news sites. It may not be the case, it may
not be what I personally think, but it's the official Debian position,
and it's not something that's acceptable for a couple more weeks.
If there's other stuff that can make it in usefully by delaying a day or
two, that's fine, but two weeks is not reasonable.
> > The point is to improve the existing stable release, whether that be by
> > adding useful features, fixing outstanding bugs, or closing security
> > holes. If the whole point of stable revisions was security updates,
> > it'd be the security team that would be managing them, not me.
> IMO, we should not make another point release, with known issues.
Your opinion's noted, but it's not going to happen. There are always known
issues. *Always*. We released potato with outstanding release-critical
bugs. Think about the definitions there.
The only thing that's worth worrying about is ensuring we don't make a
revision that doesn't include existing fixes.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Attachment:
pgpUZGgsnO9mo.pgp
Description: PGP signature