meta title="This bug's for you" So over the last week, the various items of release happiness have included:
- getting Xorg 7.1 into testing
- getting apache 2.2 into testing
- approving about a half-dozen freeze exceptions for base packages fixing RC or important bugs
- removing about a dozen RC-buggy packages with no activity or explicitly scheduled for removal
- bumping the urgency of some 20 packages that fixed RC bugs but were uploaded at low-priority despite the recommendations of the release team
- getting all the udebs into testing that are wanted for the debian-installer RC1 release, which is now going forward
- tagging all "fixed" RC bugs in the BTS with version information, so that we now have a definitive view of RC bugs left in testing
- prodding the autobuilders for retries of uncounted numbers of RC-bug-fixing packages, failed for one reason or another
- more great bugsquashing with the Cambridge BSP -- kudos to all those who helped out!
The bad news is that in spite of the time put in on whipping testing into shape, the count of bugs currently affecting testing according to bts.turmzimmer.net is still around 320, with about 210 of these unfixed in unstable; and the other 110 bugs fixed in unstable can't be ignored either, because there are many pitfalls along the way that can prevent a bugfix from reaching testing (such as a transient build failure on a single architecture that doesn't get looked at for a week or more) that require the shepherding of the release team to overcome.
Of course, some of these bugs are still false positives resulting from no one ever having checked the accuracy of closing versions on "fixed" bugs before now, but cleaning up false positives also takes time and care. Add in what looks like an average of 20 new RC bug reports a day, and it's no wonder at all that Debian can keep a release team of 4-6 busy full-time trying to get a release out.
Also on the horizon now are the ghc 6.6 transition (just 4 packages left to be fixed) and gaim 2.0 (two packages need fixed). The linux-2.6 update to 2.6.18 isn't quite ready to go yet due to some typical, new-upstream-kernel rockiness, but the kernel team are making good progress on addressing those bugs and we should see something happening here in the next week or so to let us close out our final RC kernel bugs for the release.