> Steve Langasek > It is not correct. At the time testing freezes for sarge, there are likely > to be many packages in unstable which either have no version in testing, or > have older versions in testing. The list of such packages is always visible > at <http://ftp-master.debian.org/testing/update_excuses.html.gz>. While > it's a goal of the release team to ensure that *incidental* issues don't > keep package fixes/updates out of testing, there are plenty of package > updates which will come too late for consideration, or will be RC-buggy in > their own right, that won't be part of sarge.
That's the URL I was trying to remember; thanks. That's what I meant by "the interesting thing about testing is the dependency analysis". I think the information in update_excuses mostly supports the "convergence is readiness" hypothesis. It seems to me that Jérôme's observation also takes into account the fact that "experimental" exists, so that changes that maintainers know would break britney don't get put into unstable late in the cycle. Without that, I wouldn't expect testing -> unstable convergence ever to happen. But don't you think that, until testing converges (nearly) to unstable, it's hard to know how much of testing will FTBFS on testing itself? Although it does sometimes happen that an update breaks something that works in the version in "testing", I think it's more common for an RC bug to apply to earlier versions as well, even when it's an FTBFS for something that used to build. (That often seems to mean that one of the build-deps evolved out from under the package or got removed because it was old or broken, and the source that's made it into "testing" won't build there either.) So I would expect that the vast majority of RC bugs filed against packages in sid have to be handled by really fixing them -- and letting the fix propagate into testing -- or excluding the package from sarge. Freezing base+standard at this stage saves the package maintainers the trouble of uploading to experimental instead of unstable for a while, and makes it a lot easier for the RMs to allow fixes in selectively. Otherwise, progressive freezes don't really alter this analysis. > And immediately *after* the freeze point, I think we can safely expect > unstable to begin diverging even further from testing. True enough. In a lot of commercial software development, the interval between "code freeze" / VC branch and release is necessary so that QA can finally do a full run through the test plan and the senior coders are free to fix any RC bug they can. Everybody else works on the trunk. So apply the "testing (almost) = unstable" criterion to the freeze point rather than the release point, with the understanding that the packages for which it's not true are exactly the ones that need more / different attention during the freeze than they were getting before. > While getting KDE updates into testing has been a significant task in the > past, I'm not aware of any point during the sarge release cycle when KDE has > been a factor delaying the release. Er, does the current situation fit? An awful lot of update_excuses seems to boil down to Bug#266478, and it's hard to see the RC bug count on KDE 3.2 apps dropping by much until the debate about letting KDE 3.3 in is resolved. I think the C++ toolchain issues I mentioned were a factor in KDE 3.2 propagation into testing being delayed to the point that KDE 3.3 is even worth discussing. But I haven't been following those issues at all lately, so don't take my opinion on this too seriously; maybe I should just ignore that portion of update_excuses. Cheers, - Michael
