That bugs me

Eric writes me the following:

The KPilot that ships with [SuSE] 9.1 is buggier than the one in 9.0 (as seen with two different Palms, the V and the Zire 72) and may change the times of calendar dates, so be careful when you sync and make backups of your calendar files.

And that bugs me. Not his writing, but the fact that there’s a fairly obvious regression in KPilot between those two SuSE releases.

Now, whose fault is this? Why wasn’t this caught earlier? These questions bug me. You see, I really do care about the quality of the software I produce, and though I don’t lie awake nights fretting about possible bugs, I don’t feel happy when something gets out that causes trouble for users of that software. I suppose this is the same theme as the previous blog entry bitterness prevails.

I can trace fairly closely what went wrong here: libkcal was changed to fix some bugs that KPilot worked around; libkcal also changed the semantics of some of its functions. Since libkcal isn’t public (yet) that shouldn’t be a problem as long as those changed semantics are communicated to everyone. that uses it. I might not have been paying attention that day. Since development for KPilot proceeds in HEAD, not BRANCH, the bug wasn’t noticed in BRANCH until it was too late.

So now users of KDE 3.2 branch (even the upcoming KDE 3.2.3) are pretty much stuck with a buggy implementation unless they use the KPilot tarballs from this website.

In an ideal world, four things would be different:

  • I would have all the time in the world to work on, test, and fix KPilot.
  • I would have a clone of myself so that the other guy could fix the same problems in BRANCH as I fix in HEAD.
  • Distributions would pick up the right version of KPilot somehow automagically, which means ignoring the official kdepim tarballs occasionally (certainly for branches).
  • Distributions would test the software they ship, and report problems back to the authors.

Yeah, ideal. As it stands, though, I’ve got to fix bugs where I can (HEAD) and try to put out tarballs often enough to keep abreast of the bugs. And, most important, make sure people know about them.

The Joys of CSS

Ah, the joy of CSS. I never knew them, Horatio. Or something like that. Yesterday, after Reinhold registered the domain, I decided that we’d need to update the site and give it more room to breathe; more room to reflect the ongoing development of KPilot. Since the frames-based design of the old KPilot website was somewhat broken — it didn’t adapt to changing font sizes at all — I decided that now was the moment to do something neat with CSS.

It’s been an interesting ride, so far. I’m quite pleased with the new look. Looking for CSS help was a pleasure, really, with ggl:css guide being all I needed to find such useful sites as a
guide for the unglued, which pointed me further to a guide on
css positioning. And that was all I needed to get the menu, over there on the left, to stay put, and the news items and the hardware list to behave nicely.

All these boxes being stacked vertically and horizontally made me think of TeX, the original letters-are-just-boxes typesetter, with which I can still do a lot of fancy tricks. Anyway, I hope you enjoy the new look, and remember to read about how to
help KPilot as well!

Sloans Teddy

Not much news recently, just plugging away at various buglets, incorporating patches, updating docs. The use-case “just hotsync to keep a backup of Pilot with no conduits” is shaping up well, finally. Finding the discipline to test stuff thoroughly is .. difficult.

Testing KPilot is one of those things that really takes the fun out of developing it. Whereas for lots of KDE applications you can just recompile, click, and see the results of your fixes, KPilot is different – and much slower. Suppose I’m working on the KNotes conduit; copy handheld to PC isn’t working quite right (this is bug 69595). When I make a fix, I need to:

  • switch to another user (to save my own data),
  • check the state of that user’s knotes and kpilot directories,
  • check the state of the Palm m105 I use for testing (this may involve hotsyncing it to a known state with pilot-xfer),
  • start KPilot
  • perform the hotsync
  • check the state of kpilot and knotes for the results

This is a turnaround of, say, 10 minutes, and it requires special attention to detail in some of the steps, and it takes batteries too.

Using the PalmOS simulator POSE isn’t that big of a help, since it’s crash-prone (at least on my Debian box, and on FreeBSD it doesn’t run at all), and the syncs – the most time consuming part of the operation – take just as long.

Finally, checking the results isn’t something that can be done mechanically, at least not easily: I need to view the contents of Palm databases (in KPilot) and check the data held by other programs (like KNotes). If it was a matter of comparing some md5 sums, it would be much easier to see if I had the right results for a particular test.

Lest it seem like I’m merely complaining: I’m not. I’m admitting that I like coding more than testing. I’m admitting I like the cheap thrills of instant bug-fixing gratification, and that slow test cycles take those thrills away. I’ll even go so far as to say that I have great admiration for folks that can stick to test-based software development – most of the time I can hardly describe beforehand what it is my software is supposed to do, let alone figure out how to check it in an effective manner.

That said, it’s back to the old grindstone …

(The title of this blog entry is of course derived from a singularly lousy pun which appears in one of Asimov’s “postcard stories.” It took me years to understand it.)


Bright and shiny patches came in from several people over the past few days. Jörn, David, Sebastian all fixed minor irritations. Reinhold did his usual excellent work, implementing wizards and neat stuff. All this cheers me up no end. Thanks guys.

Bitterness Prevails

Indeed it does. You know, folks, I get a couple of bugreports a day. Sometimes with thanks for the parts of KPilot that do work — and I am profoundly grateful for those thanks. Unfortunately, I don’t have much time for KPilot. I do my best to deal with troubles, but there’s a lot of them, everything keeps sliding out from under KPilot, and I feel swamped. And bad about the number of bugs.

So what would really really make my day would be patches. To anything. See, one of the tenets of open-source software is that people with a vested interest in making an application better — that’s y’all who would like to use KPilot — will also put in some time and effort in making it better. And that means patches. Really.

Picking up the Pace

Ok, my new machine is installed (and amd64 running FreeBSD -CURRENT, which puts me firmly at the forefront of things-unstable). It runs KPilot 4.4.0 from KDE CVS HEAD, though, which is a good thing. Of course, having a new machine means spending lots of time figuring out its quirks and installing all that software that turns out to be essential.

I really like FreeBSD for its approach to additional packages: don’t install them unless the user asks for it. The ports system works really well, but it’s always painful on a new machine when I need to draw a diagram now and discover that XFig hasn’t been installed yet. It’s a quick fix, but it bugs me.

Anyway, I can still work on KPilot ..

For KDE 3.2, KPilot 4.4.0 will be the norm, and it’s a little wonky still. I will be putting up updates on the site along with an updated build system, so that users can fairly easily upgrade while ignoring the string, feature, and everything freeze.