On Mon, Oct 25, 2004 at 01:05:51PM -0700, Thomas Bushnell BSG wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:
> > * One of Testing's goals was to be 95% releasable at all times.
> > * It hasn't been.
> > * Why not?
> > (a) RC bugs
> > (b) Can't install it
> > (c) Security vulnerabilities
> This is the crux of the problem, I think, but I'm a little confused.
> How does (a) contribute to this? The assumption behind an RC bug is
> "we can't release with this bug unfixed". But the problem is that, of
> course, we *do*, and we *have*, because many RC bugs are in things we
> have already released.
To paraphrase: "The problem is that, of course, this is not a problem."
Releasing with a hundred known security problems in the kernel is
worse than releasing with a dozen unknown security problems in Priority:
extra packages. We can, and indeed have to, accept the possibility of the
latter; we shouldn't accept the former. The existance of various RC bugs
in woody, now or when it was released, and the number of RC bugs still
present in testing sit somewhere on that scale between those two extremes.
Where we chose to make a cut off point and release is likewise somewhere
between those two points.
(a) is about failing to make sure we're on the correct side of that cut
off point.
> So the RC bugs should not be blocking release unless they are *new* RC
> bugs which don't already exist.
That's not really the case. Though, even if it were, sarge would still
fail to be releasable.
> As for (b), the solution, if there is one, is to have the installer
> folks spend time targeting testing all the time.
In my experience, claims of the form "The only possible solution to this
problem is <foo>" are almost invariably wrong, or at least need to be
heavily qualified.
The drawback is that "targeting testing" for development work is usually
a losing proposition -- there's a deliberate delay in putting stuff
into testing, and any delay is a nuisance when you're waiting on a fix
before you can do more development. Even targeting unstable has proven
cumbersome for the d-i folks.
> As for (c), the solution in my opinion is to allow security fixes to
> migrate into testing without having to wait for the normal delay.
That already happens, just set urgency=critical in the changelog. If
you forget, reupload, or contact a release manager.
It's not enough, because security bugs aren't always fixed in a timely
manner in unstable; see [0] eg. It's also not enough, because uploads
to unstable can easily be unsuitable for testing, even through no fault
of the package's maintainer.
Is it coincidence that all your proposed resolutions involve
situations where you couldn't be expected to contribute? (RC bugs don't
matter! Installer team needs to refocus! Security stuff is already
handled, just needs code changes!)
Cheers,
aj
[0] http://lists.debian.org/debian-release/2004/08/msg00174.html
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
Don't assume I speak for anyone but myself. GPG signed mail preferred.
``[S]exual orgies eliminate social tensions and ought to be encouraged.''
-- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)
Attachment:
signature.asc
Description: Digital signature