Re: Drop testing
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. In other words, woody has RC bugs in it Right
Now. But that doesn't stop us from continuing to call it stable.
So the RC bugs should not be blocking release unless they are *new* RC
bugs which don't already exist. In other words, a new stable release
shouldn't be worse, but it doesn't have to be maximally better. It
shouldn't have new RC bugs, but it's tolerable if it continues to have
the same old ones.
As for (b), the solution, if there is one, is to have the installer
folks spend time targeting testing all the time. I don't know if this
is actually worth the effort or not.
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.
Thomas
Reply to: