Re: Current 2.2r2 status
On Thu, Nov 23, 2000 at 01:28:13AM +1000, Anthony Towns wrote:
> 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
> 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?
I wasn't organizing a show stopper list for 2.2r1 :)
> > > 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.
Two weeks is for holidays, which Thu is one of the most major ones for
the US. I can't justify not eating thanksgiving dinner with my family (and
I'm sure others in the US will agree) just to do Debian stuff. On top of
that, I said less than two weeks, which is just to give the ports time
to do boot-floppies + testing. We don't want to just make uploads and
release without any testing.
> > > 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.
Point releases are supposed to be better. If the number and severity of
known issues is the same two days after release, then we didn't do that.
There is a list of known security updates that are being worked on. Those
need to be handled. However, those things wont take as long as the other
issues, such as boot-floppies with updated base2_2.tgz. That also hinges
on the security fixes.
So the show stopper is to get boot-floppies rebuilt, and proposed-updates
merged. The long term isn't proposed updates, it is boot-floppies. Now
this might be done in several days, but the fact is it wont be available
for long enough that the ports can test it for a day or two to make sure
we don't end up with uninstallable archs. Unless your only concern is
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` email@example.com -- firstname.lastname@example.org -- email@example.com '