"Monique Y. Herman" <[EMAIL PROTECTED]> writes: > Say you have package A that makes it past unstable and into testing. > Then someone finds a bug in package A. It turns out to be an icky bug, > and it takes quite a while to fix it. The bug will be fixed in unstable > before trickling down into testing.
Actually, the real problem with running testing is that the dependency graph involving the 13,000 or so packages in unstable is so complicated that enough bugs can crop up (especially during transitions) that nearly the entirely distribution blocks itself from entirely testing (because a bug in one package is holding back another package, which in turn is held back by another bug, etc.). In this situation, it becomes computationally impossible for the testing scripts to unlock it. To work around this problem, the testing release manager will manually force the more critical packages into testing from time to time, intentionally causing major breakage in a lot of other packages. Then, the rest of the packages will be allowed to trickle as an normal, which can still take several weeks. Thus, many packages can be broken for quite a while. My opinion is that testing should not be publicly available until it is in the "release candidate" or "beta" stage, or whatever you want to call it. Up until that point, it should be a virtual distribution only existing in the output of the testing scripts. I think it does a disservice to the community to have a publicly available distribution that appears to be a compromise in between stable and unstable, but in actuality can be much more broken than unstable. It's also a real pain for maintainers because we get many bug reports from testing users that, although are valid, are completely unfixable by maintainers. The only fix is waiting, possibly for quite a while. The real bug is testing itself. -- You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
