Heh, thanks zack for your welcome. :) I'm afraid I don't make bug fixing look as easy or as organised as you do.
Some cheating to finish off the weekend: #548860 was reopened accidentally, #555898 was already fixed in another package, and #555939... actually, that did need a fix, but I just munged the test suite to expect some new error output.
Then I spent this morning writing half a testsuite for svn-buildpackage, and this evening just zoning out.
Sometimes I wonder whether fixing RC bugs is actually improving the quality of the release, or just letting us make a buggy release sooner. Non-RC bugs get pushed to the back of the queue. Hmm. But the pkg-perl team has around 170 packages with bugs in, and not that many people fixing bugs. I have to agree with corsac on the general point that just about everywhere in Debian could use more people.
There's a huge role for non-DDs to play in getting fixes into Debian, but as far as I remember, the emphasis of the mentors documentation is on packaging rather than bug fixing. I was barely aware that I was even allowed to prepare an NMU. And from what I know of the NM process now, a huge list of RC bug fixes would go a long way to establishing credibility as a potential DD - longer than a huge list of poorly-maintained packages.
It seems to me that the mentor relationship works better when DDs get to know particular people, and regularly sponsor uploads for them. This way they are in a better position to advise and sponsor any NMUs that might come along, and eventually to advocate them as an NM candidate. But it also seems to me that debian-mentors is not geared up for this at the moment.
To conclude, it's 1am, and I shouldn't be posting controversial thoughts on my blog. :)