I ve got a bit of a problem.
I enjoy writing software. I often write software to solve some sort of problem that I ve had. Usually virtually any code I write winds up in my
git repositories, on the theory that it might be useful to someone else. Some of the code that I think might really be useful to people gets even better treatment.
OfflineIMAP, for instance, has a very
comprehensive manpage, heavily commented
example config file, wiki, mailing list, public bug tracker, etc. Most of these I did the majority of the work to create, but OfflineIMAP does occasionally receive code and documentation contributions from others.
Now here s my dilemma. For my purposes, OfflineIMAP is, well, finished. It does everything I ever wanted it to do, and does it better than I ever expected it would. There are some people that would like it to do other things; for instance, optimize performance for IMAP folders with 100,000 messages in them, do UTF-8 folder name translation, and retry a sync if a connection is lost rather than crash (OfflineIMAP was designed to crash gracefully and be automated, so this has never bothered me.)
None of these are features that I care about, and I don t have much time to devote to OfflineIMAP these days. It is not an interesting problem to me anymore as, well, I ve solved it already.
Yet I ll be honest and say I feel guilty about the bug reports that are stacking up in the OfflineIMAP bug tracking system. OfflineIMAP is used by people that have an expectation for improvement. My efforts to hand over maintainership of OfflineIMAP have failed (the people have gone AWOL shortly after agreeing to maintain it).
This problem is even more acute for
hpodder, my command-line podcatcher. hpodder works great and is simple. But I no longer listen to podcasts. At all. (I blame my Kindle for that.) Therefore I no longer even use hpodder. Again, I feel guilty for not working on it; for instance, when language changes broke its UTF-8 support, I haven t gone in to fix it. Neither has anybody else, for that matter.
This leads me to a dilemma. If I do nothing with my code but toss it on git.complete.org, few people will benefit from it. Most people need documentation, packages for their distribution, etc. git repos don t tend to show up highly in search engines. So, although technically I ve shared things with the world by putting them there, practically speaking I haven t done people many favors.
On the other hand, if I go the whole responsible maintainer route, writing documentation, wiki, mailing list, Debian packages, etc., then I have the problem of, well, actual users who want actual support. I feel bad if I m not in a position to give it to them. Many people seem to have the expectation that software is never finished and will continue to be improved. (Ah, if only my name were Knuth I might stand a chance to evade that one. But only a chance, given all the TeX spinoffs.) This expectation, in turn, reduces my enthusiasm for publishing my code online as Free Software. Because now I can t just toss it up there and say help yourselves . Now I get angry emails about all the bug reports piling up. On the other hand, I also get occasional small contributions via my PayPal tip jar , which are awesome and motivating.
Despite my grumbling, I do continue to maintain OfflineIMAP, primarily as a patch reviewer these days. I take an aggressive stance on quality, and when I get patches that add features without documentation, I usually write documentation for them before committing them. If I have evidence that a patch hurts quality, I yank it (as I had to do with IDLE support, which was a great feature, but the patch caused all sorts of stability problems due to its requirement of imaplib2.py). For that reason, I suspect, forks haven t taken off.
So what s a person that writes niche software to do? OfflineIMAP isn t at the level of popularity of something like Gnome, or even debhelper, and never will be; its userbase consists of people that think that IMAP support in $MUA isn t good enough. hpodder is the somewhat small domain of console-loving podcast listeners.
What are your suggestions? Should I abolish the bug trackers and just go for simple? Is there something more I could be doing to make the community feel more empowered? Is simple posting on git.complete.org not as bad as I thought?
When I got my Mac Mini, one of the very first things I did was to test the Debian build of rEFIt on the machine, given the EFI firmware is x64 on the newer machines whereas it s ia32 on my MacBookPro; it was the very first time I could test the x64 build.
And the results weren t good: some images couldn t be loaded, and it all seemed to be random.
Disabling optimization in both GNU EFI and rEFIt for the x64 builds helped somewhat, at least it made rEFIt reliable enough to be usable.
Now, with this new release, I started getting error messages, requiring a key press before the menu would be displayed. It s annoying but it s also very helpful as I now had an error message to work with, and even if the error message wasn t reliable, it would still point me to some part of the code. The message was: Invalid argument.
On x64, the use of a call wrapper is mandatory because the EFI x64 calling convention doesn t match the calling convention of the ELF executables we re building and later disguising as EFI executables. The call wrapper has always been the prime suspect in this issue, it d be an obvious candidate for anyone looking at this issue.
Today, digging into the issue with some new data, I realized what the problem was: when using the call wrapper, all arguments need to be of the UINT64 type. That s the type the call wrapper uses when extracting the arguments from its va_list.
Introduce some more macros on top of the call wrapper, build, test: voila, it s fixed! That was tricky one.
Let s sum it up for the search engines: all the arguments to the EFI interface called through uefi_call_wrapper() in GNU EFI need to be cast to UINT64.
rEFIt 0.14-1, available in unstable in a couple hours.
Next, I ll see if I can reenable optimization in both GNU EFI and rEFIt.
Last Friday and Saturday the second 
I've now 
I'm changing jobs!
From June 1st, I will be team leader of the Computing Support team for the
School of Computing Science at Newcastle University.
I will be leaving my current job as a Computing Officer within the central IT
department's UNIX infrastructure team (ISS). My professional career began
within ISS nearly 6 years ago. I have made many friends and will miss working
with them as closely as I have.
I am really looking forward to getting stuck into my new role. Working within
a school means I will be a lot closer to the University's business of teaching
and learning. As a Computing Science graduate I've always had an interest in
computing research and my new role will have me up close and personal with
world-class researchers.
A few months ago, I wrote about 
Bravo Greenpeace Switzerland! At 
That was a pretty good weekend. I set up someone s new Samsung N150 netbook with 