This is the first of my two formal reports to the Dunc-Tank board on the release management funding experiment. Although submitted to the board some time earlier, I've delayed publishing it to the wider community until a release update could be sent out with more concrete information on timeline adjustments as Debian developers are wont to demand.
I'm supposing that I don't need to give you any more specific details on what I've been working on than what's already been posted in my blog. There has certainly been plenty to keep me busy the past three weeks, including a lot of triage work on the state of bug reports in the BTS, managing the last of the major package transitions into testing for etch, removing packages and NMUing them, and it has indeed kept me busy. Busy enough that I've been lax when it comes to talking about it, either here or in my blog. :)
Has the hard work paid off? Well, http://bugs.debian.org/release-critical/ shows a sharp decline in release critical bugs affecting testing over the same time period, following the peak resulting from Dunc Bank's successful campaign of identifying latent release-critical bugs in etch. Unfortunately, we have no statistics that track the number of RC bugs closed or opened over time, which makes it hard to judge how large of a dent my own work has made in the overall bug count. It's also totally guesswork to try to judge whether Dunc-Tank has encouraged others to help with the release overall, or discouraged them from doing so. What I can say is that, even though the past month coincides both with the tail-end of the Dunc Bank mass bug filings and multiple archive-wide rebuild efforts, the bug count is moving in the right direction, and I am seeing many maintainers being responsive to bugs in their packages and a number of active NMUers. If not for the buzz-kill of Lucas Nussbaum's latest round of build failure reports :), we would be down from over 300 RC bugs to less than 200 right now, which probably represents at least twice that many RC bugs closed.
In terms of how the time I'm putting into this release compares with the sarge release, I'd say it's pretty comparable. That's actually quite a positive statement about Dunc Tank's role, IMHO; getting a Debian release out is uphill all the way, and whereas the sarge release came at a time when I was in a position to work more or less full time on it without compensation, my availability this time around would have been greatly reduced, and progress would have been much more heavily dependent on individual maintainers and semi-periodic bugsquashing parties, which I'm not sure is any longer enough to offset the rate at which new RC bugs are created in the distribution by uploaders.
As it stands, I do find myself trying to consciously avoid a hero complex of needing to fix every bug personally, but there are after all only so many options for getting bugs fixed for release. A lot of maintainers respond positively to gentle nudging about their RC bugs, but there are still bugs that the maintainers can't or don't fix and that no NMUers take on, which does leave it more or less up to the release managers to address -- which is why one of my tasks for this week is to try get the count of RC bugs over 20 days old down from 90 to around 20-30, as these are the bugs that really do need more attention to get them resolved.
So yes, Dunc-Tank is making a positive difference. Andi and I have reviewed the status, and while we don't think we'll be able to hit the Dec 4 deadline (even if we get the bug count down immediately we're waiting on the debian-installer to release, which needs at least one more release candidate with the 2.6.18 kernel), we do believe that a release before the end of the year is very possible and I'm looking forward to starting the full freeze in the next few weeks.