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 <[EMAIL PROTECTED]> <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)
signature.asc
Description: Digital signature
