The shoemaker's son always goes barefoot

I admit it. I’m a terrible developer. I write code, sometimes even write tests.

But. I. don’t. test. my. programs.

By hand, that is. And sometimes (usually) the coverage is not enough, and I end up making embarrassing mistakes. It usually happens outside of work, although at work I also have my share. The last one was with the Debian package dhelp, where trying to fix an issue before Lenny is released, I ended up making it even worse. The story goes like this:

There was some problem with the indexing of documents on installation/upgrade (namely, it would take ages for most people upgrading to Lenny, and they would think the upgrade process had hung). So, I go and change the indexing code so it ignores documents on installation/upgrade. Also, as suggested by someone, I created some small example utility to reindex documentation for certain packages. I test installation, upgrades, upgrade of the dhelp package itself, the utility, searching for keywords before and after all that… and everything worked.

Only that I made a typo. A typo that would make all indexing to be ignored (except for the example utility, because it was a bit lower level). And I didn’t realise, because it “only” broke some cronjob, a completely different part of the package. And it happens that the cronjob reindexed everything weekly, to make sure that you had reasonably up-to-date search indices. And it also happens that, given that the documentation reindexing was being ignored on package installation/upgrade, the weekly total reindex process was the only thing that could provide the user with indexed documentation. But I screwed up. Oh well.

Someone filed a bug yesterday, and I fixed more or less right away. But this time I spent a couple of hours thinking of test paths and ways to make it fail, and actually doing all that testing. Thanks to that, I found some potential bug in the example utility, that I fixed just in case. So hopefully everything is fine now, if I can convince the Release Masters to allow the new, less broken update to dhelp to be accepted for Lenny.

I think I need personal QA. Anyone up to the task?

• developer
• dhelp
• qa
• testing

dhelp goes international

Some good news in the dhelp front: after talking to some people and a couple of messages in debian-i18n, dhelp has (hopefully) full support for UTF-8, and two more translations, the first two apart from the Spanish one: Russian and German. It’s really cool seeing some program you have written producing output in cyrillic ;-)

I haven’t uploaded yet, because I found two new strings that weren’t in dhelp.pot, but I’ll upload soon, when I receive the updates for the translation. The UTF-8 update is related to some improvements in doc-base, so things are looking good in the documentation tools side of Debian, yay! :-)

• dhelp
• i18n
• utf8

Big changes in dhelp

As I said earlier, now the fun stuff begins :-) I have been working with dhelp these days, and there are a couple of things I have changed already:

• I have dropped support for the dhelp-specific .dhelp files. Now I just use the doc-base information directly (until now, doc-base had to convert its own format to dhelp, which was a bad things for several reasons, one of them losing important information in the process).

• I have changed the indexing code so it now indexes the actual documentation content, instead of the documentation directory generated by dhelp.

• I have rewritten most of the HTML used in the searches and in the documentation directory so it’s nicer and easier to modify (e.g. no more <font> or similar obsolete tags).

While working on the indexing changes, I have been playing with swish+++, an indexing engine. Seems really useful, although some options are not that obvious, and I haven’t been able to use extract++ to extract the text according to the file format (e.g. skipping HTML tags in HTML). I’ll keep trying…

Hopefully, the package will be ready for release in a week or so…

• dhelp
• index
• swish

Fun with dhelp

I finally uploaded dhelp to unstable, and everything went almost surprinsingly good. The only bugs reported so far are #448211 and #447789. The first one was a silly mistake made by me, in some translation files that aren’t even being used now (that will change in the near future). The second was a bug exposed by dhelp, but actually in another package (libcommandline-ruby, which is funnily enough also maintained by me, and it’s already patched and pending upload).

So, now that the package is uploaded and we’re using a sane implementation for dhelp_parse, I can start doing fun stuff. Right now I’m mostly fixing more bugs, but I’m also implementing new features and talking to the doc-base maintainer, to improve the integration between both.

• bugs
• dhelp

Dhelp's new release

Dhelp’s new release is coming along nicely. In the last days I have fixed a couple of bugs in @dhelp_parse@’s rewrite, and I think it’s now ready for upload. The new package closes 28 bugs, which is more than half the current open bugs for the package.

I have warned the current maintainer and the debian-doc mailing list, so I hope to upload the new version in a couple of days…

• bugs
• dhelp
• package
• upload

Dhelp strikes back

In the last days I have gone back to working on dhelp, a Debian package for documentation indexing and search. Months ago I had started rewriting dhelp_parse, the only program in the suite written in C, in Ruby.

The rewrite was almost done, but the program wasn’t tested much (some modules had unit tests, but the program itself didn’t), so I found a couple of big bugs easily :-D Now it looks better, so hopefully I’ll be done soon, and I’ll upload the new package to Debian so people can start testing it.

• dhelp
• packages