I thought I should share my current favourite Ubuntu patch. While hunting for easy RC bug fixes yesterday, I stumbled across mit-scheme_7.7.90+20090107-1ubuntu1.patch [roughly 9MB]. It contains a Debian .deb to bootstrap the Ubuntu mit-scheme package (bug filed). Nice. Now, to be fair, Debian has a bootstrapping problem for mit-scheme as well - it requires itself to build, but is currently uninstallable in unstable (although zack's on the case). Having looked at the problem, I think the best thing to do in the long term would be to package mit-scheme-c (which appears to be a superset of the upstream tarball for mit-scheme?) and then use that to build the other package. This would also provide a version of mit-scheme for arches other than i386. If maintainer-built binary packages are going to get thrown away at upload time, that would have been the only way to solve the bug, I think. (I don't mean to fuel the Debian vs. Ubuntu flames; it would have been nice if the MOTUs could have fixed this in less of a hacky, license-violating way, but they did at least get the package to build, which is more than Debian can do at the moment. I intend to keep a closer eye on Ubuntu bugs and patches for the various packages I work on, because keeping divergence to a minimum should benefit both distributions.)

I've been slacking on the RC bugs front. :) Let's see, my last blog post was on Monday 16th, so I'm late...

• 2009-11-17: #527838 in 'smart' - investigated, closed as fixed. (Blatant cheating.)
• 2009-11-18: #516338 in 'pornview' - debugged a segmentation fault on amd64
• 2009-11-19: #551251 in 'libjavascript-perl' - patch written, but need to finish off and release.
• On Friday I looked at postgresql-pllua and postgresql-plproxy, but they need a bit more work than I originally thought, so I joined the pkg-postgresql team. I'm amazed I wasn't a member before, in fact. :) Now just need to actually update the packages.
• Then I took the weekend off! Went out, had fun...
• Yesterday I followed up on bug #516338 above with a delayed NMU, but I believe we're close to a maintainer upload now.
• 2009-11-24: #553230 in 'libapache2-mod-macro' - NMU diff written. I think it's borderline removal material, since there's only been one maintainer upload ever, but it does have a few popcon votes.

The DELAYED queue is a wonderful mechanism for reducing the amount of busy waiting that needs to happen for NMUs; you don't have to remember to come back and upload several days later. For non-DDs, it takes a bit more co-ordination between you and your sponsor, unfortunately - do you send the NMUdiff to the bug before you get sponsorship, and risk having to change it? And then revisit the bug to give notice again once it does get sponsored? Or leave it until after upload, which might reduce the amount of notice you're actually giving the maintainer (if, say, your mentor is in a different timezone)? I've been opting for the first approach, but it doesn't have the same fire-and-forget quality of the real thing.

This evening I investigated #555941 in libxml-filter-xslt-perl, and was able to downgrade it to "important". I'm working on a proper fix, but it's not RC any more. (Gunnar, I don't mean to make you feel bad! I've been inactive for a while myself - I'm just making up for lost time.) And now for conversation via blog! Clint, I'm inclined to agree about ego, fiefdoms and so on. But I'm unconvinced that personal relationships themselves are harmful. Actually, I was thinking more about "professional relationships" - I don't care much whether mentors take their mentees to an art gallery, provided they work with them over a period of time, and therefore get to know the quality of their packaging. (I was a bit careless in my phrasing last night.) Having said that, let's do that as well! Indeed, building relationships so that we don't flame each other to a crisp the rest of the year is the very reason we hold DebConf, right? (Apart from the beer. And the holiday.) I reckon the mentoring system would be more effective if we started thinking along these lines, and this in turn would help address the wider problem of resources within various parts of Debian. Maybe not directly, but it could free up other people to work on the complicated stuff. We could probably turn debian-mentors into a sort of "team" in its own right. (Apologies if someone's suddenly made debian-mentors active again behind my back.) And if I ever get approved by DAM (ahem), I intend to propose a deal to the debian-mentors list that each upload of an updated package will cost them one RC bug NMUdiff, and uploads of new packages will cost two. ;)

Debian is primiarly organized into mostly one-person "projects," namely packaging a piece of software. But in the past few days on Planet Debian, there has been discussion about how existing packages in Debian need more help. Tim Retout wrote:

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 think this is a serious problem across Free Software. Open source contributors are grouped into projects. If you're burning out on what you're working on lately, or you are looking to become a new contributor, it's hard to know what projects need your help. As someone who knows Python and Debian packaging, it would be nice to be able to search Debian for Python-language packages that need help. I also think that Tim hit on a really important social point later in his post:

It seems to me that the mentor relationship works better when DDs get to know particular people

Tim's right that personal relationships make a big difference. I got serious about my NM application when I asked someone I already knew to sponsor my packages. But not everyone can be so lucky as to have a Debian Developer as a friend. And many projects aren't as friendly as Debian; there's no official mentorship available. I think that we need to start paying a lot more attention to personal relationships all across Free Software. (I'm working on a web tool in this space. Join me in #openhatch on irc.freenode.net to discuss it, or just stay tuned until I write it up tomorrow.)

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. :)

On Wednesday, I fixed #551228 in libgstreamer-perl - from the bug log, it looked like it would be an intriguing parallel-build problem, but I reckon it was just a faulty test. Next I applied a patch from the upstream bug tracker for #544894 in libtk-filedialog-perl, which was fine; but then we noticed that there was no explicit copyright notice in the source, so it hasn't been uploaded yet. The code is from 1996, so we would request removal from Debian if it weren't for 'horae' depending on it. Hmm... Then yesterday I found the time to test #520406 in libdbd-mysql-perl, which I remember being open as long ago as DebConf. It turns out it's dead easy - there's already a test case and a patch upstream, which was applied a while ago, so the bug is already fixed in squeeze. Today I prepared an updated package to fix this in lenny. So, I'm still falling short of one RC bug a day, and pkg-perl has more RC bugs open than at the start of the week. :( The weekend's not over yet, though.

Hello, Planet! (Thanks to lamby for adding me to Planet Debian.) If you don't know me... I'm not surprised. I do some occasional pkg-perl work, but I've really been slacking (and changing jobs, and moving halfway across the UK). Last week I fixed one RC bug, in libgnupg-interface-perl. Better than none, I suppose. It turned out to be quite interesting; the tests failed when the package was built on the buildds, but not locally. Other people had done the hard work, and figured out that this was happening when there was no tty; I just had to debug why the particular perl variable was getting unset. I'm somewhere near the end of the NM process; one of these days, I'll be able to upload my own packages, and those of other people. I'm still working out where best to apply myself within Debian - I do want to share some of the pkg-perl upload burden (because gregoa is an absolute hero, and deserves to be able to take holidays). The status of Debian mentoring in general intrigues me; there seem to be so many places where more minds are needed, and perhaps this makes encouraging and training new developers especially important. More on this later.

A few days ago I was awarded official Debian Developer status. Many thanks to:

• Thomas Viehmann
• Ana Beatriz Guerrero L pez
• Daniel Baumann
• Christoph Berg
• Thomas Bushnell, BSG
• Stephen Gran
• Steve McIntye
• Neil McGovern
• Cyril Brulebois
• Matthew Johnson
• Sune Vuorela
• Peter Palfrader
• Jonathan McDowell
• Tim Retout

For posterity, my first experience with the Debian development process was with #400550. Never underestimate the importance of giving credit in changelog entries.