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.)
Posted: 26 Nov 2009 21:31 |
I've been slacking on the RC bugs front. :) Let's see, my last blog post was on Monday 16th, so I'm late...
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.
Posted: 24 Nov 2009 22:08 |
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. ;)
Posted: 16 Nov 2009 21:24 |
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. :)
Posted: 16 Nov 2009 01:09 |
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.
Posted: 14 Nov 2009 15:42 |
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.
Posted: 09 Nov 2009 23:42 |