This weekend we, the KDE PIM developers, met again in Osnabrück to develop and discuss the future of kmail, korganizer, kjots, akonadi and other software for Personal Information Management.

There you can find all meeting minutes, time tables and results, here I want to outline what was most important to me.

At work, I stumbled across a problem that I want to declare as universal. I got a mail with a title like

christmas party invitation

I deleted this mail without reading because I knew I would not go there. Fine so far. But later I found out this mail contained one sentence that actually was of interest to me:

"due to the preparations of the christmas party, the canteen will be closed starting 12:30"

I recently had a crash that was hard to fix. Well, it IS hard to fix because I am still on it. It is again one of these "from the middle of nowhere" bugs KDE is so good in producing. I means those bugs that originate from a wrong-understood idea of automation. The programmer does not have to do anything because the framework will do it for him. Super. That leads to a problem if the framework does not do it correctly. The programmer will not see any way how to debug the problem at all and will have to become a framework-developer.

Some weeks ago, someone posted a question on the KDE PIM mailing list "Which IDE do you use" or so. This reminded me of the ideals of my youth when I believed that the better your IDE - the more efficient your programming work - the more you get done in a given time for your software development.

It is often said that many open-source-software is not enterprise-ready. But in order to be enterprise-ready, software must first be user-ready. I want to give you a feeling what I mean.

Today I fixed a bug that has been open for more than 4 years. This feels good. However, there is a reason why it took so long: kdialog contains a member winId() as you can see here, but this is not documented in our api documentation.

Writing good error messages for your programs is art. Your user gets an error message - he cannot ask his computer "how do you mean this?". Error messages are important because they can help you fix a problem. Some error messages are critical because the error prevents you from achieving anything. One example are the error message of startkde. When you have a problem with startkde, you have a real problem. If you cannot solve it, you cannot work (with KDE) at all.

As I pointed out recently, I only develop KDE in a virtual machine. It does not only enable me to rollback changes that screwed up something, it also allows me to go back to a verbatim snapshot where I can e.g. be sure that there are no mysterious plugins installed to directories that I have not thought of. I also pointed out that compiling in a virtual machine is slower, because you cannot use more than 2 processor cores per virtual machine. No problem!

When I heard that Nokia was giving away N810 devices on aKademy, I wondered how long it would take till I saw the first code changes. So, code changes to support the ARM architecture or the use of KDE on a PDA. Today I saw three (and wrote two of them):

• Require at least Strigi 0.6.0 (SVN trunk) because a BC change was needed in libstreamanalyzer to support ARM architecture.

Many of us know this: You are on KDE version "from yesterday" and suddenly, everything breaks. Maybe someone broke the kompile or it is just a bunch of bad code that went in before your checkout and prevents the window manager from starting.

You learn from this mistake, you no longer install to /usr, but you create a dedicated user for your KDE programming fun. Soon, the next painpoints arise:

• you cannot test the display manager
• you cannot test the latest system-wide dbus stuff