Akonadi Meeting and the KDE SC 4.5 release

14 05 2010

The meeting

We are at the Akonadi meeting at the KDAB offices in Berlin right now, which was quite nice so far. We had the first round of API review of new methods in KDEPIMLIBS for 4.5, and already cleaned up quite a bit. Having multiple eyes look at the API is a nice way to improve the overall quality of the API. We met with Andrey Moiseenko and Alvaro Manera of Nokia, who work on calendaring for the next Meego phone from Nokia. They use our KCal library, which they have forked/extended for some special requirements they have. We’re now making plans with them to integrate their changes back to our version of KCal, so that both sides will profit from changes and have a single point of maintenance.

The release

Many of you are interested in the state of KMail 2, which is the port of KMail to the Akonadi PIM framework. We haven’t communicated much about that lately, as most of us aren’t keen bloggers¹. Finally, here is an update for you now. Yesterday, we had an intensive discussion about the state of KMail 2 and our release plans for it. While we made some good progress on it in the last few weeks, we came to the conclusion that KMail is not yet in a state that is suitable for a beta release. With the KDE SC 4.5 beta 1 release approaching fast, we had to go for some plan B. KDEPIM will not be included in KDE SC 4.5 beta 1. Instead, we will concentrate on making KMail more stable and usable, and release the first beta version of KDEPIM one month later, at the time when KDE SC 4.5 RC1 will get released. That gives us some time to finish important bits and bring KMail 2 to a state in which it can be used.
This means that there will be no fresh KDEPIM packages in KDE SC 4.5.0, and distributions should ship the KDE 4.4.x version of KDEPIM instead. The final KDEPIM release will then follow a bit after the SC 4.5.0 release, at the same time as KDE SC 4.5.1.
KDEPIMLIBS is not affected, it will be released together with KDE SC 4.5.0 as planned. The rest of KDEPIM progressed very nicely: Tobias fixed a lot of problems in KAddressbook and brought back some missed features. The Akonadi port of KOrganizer is also working quite well. However, releasing KDEPIM without KMail is not an option, as it is a quite important part of the PIM suite. We briefly pondered replacing KMail with an older version for the release, but that would involve ripping apart and moving around the dependencies, which is a lot of work and has a high risk of regressions. I think delaying the release is the best option here, as it gives us some more time for stabilizing without too many downsides.
If you’re a KDE developer, please try out the beta version of KDEPIM when it gets released and help us making it work for your usecases. I hope the revised release schedule will work out, keep your fingers crossed 🙂
So basically the release of KDEPIM will happen a bit after the KDE SC 4.5.0 release. We’re not sure about the release name yet, maybe we should call it “Preview” or something like that, just to prevent the endless discussion and flames about naming that happened with the KDE SC 4.0 release.


KMail 2 is a major rewrite of KMail: We throw out the ancient brittle storage layer and replaced it with Akonadi. On top of that, we ported it from the mimelib library to KMime. Finally, we factored out much of KMail into separate libraries, such as Akonadi itself, the messageviewer component, the messagecomposer library and more. That allows us to re-use those components in other applications, such as the mobile version of Kontact, and makes it possible to unit-test the components, which was not possible before, as everything was tightly glued together in KMail.
Such a major rewrite is not without consequences: On the one hand, it will finally modernize the complete architecture and make it maintainable. On the other hand, such rewrites always introduce regressions and remove features. This is unavoidable, and it is always a compromise between releasing and between stabilizing. Software would never get released if the requirement would be to make it regression-free and feature-complete.
What does that mean for KMail 2? With the first release, some features will be missing:

  • There will be no on-server filtering for POP3. I guess most people weren’t using this anyway, as it was actually quite hard to configure this correctly in KMail 1. Normal client-side filtering will still work, which is what everyone uses.
  • There will be no attachment loading on demand for IMAP. In KMail 1, with online IMAP, it was possible to activate loading attachments on demand, which means attachment will not be downloaded when viewing a message, but only when the attachment is actually saved to disk. This had some problems in KMail 1, like attachments having a size of 0 bytes, but it also sometimes worked. While the Akonadi architecture supports retrieving only parts of items, we don’t use that yet in the message viewer.
  • The most hated KDE bug will not get fixed. The bug is that KMail’s UI will freeze when the incoming mails are filtered, which is especially annoying for slow filters, like the filters that pipe the mail through spamassassin. That is not a regression from KMail 1, but we had hoped that the bug would be fixed with Akonadi. The idea is to use a filtering system which runs in a separate process in the background, instead of doing the filtering inside of KMail. Such a filtering system was created in a summer of code project last year, but due to lack of time, it is not yet integrated in KDEPIM. That means filtering will still be done on the client-side in KMail, with the consequence of freezing UI. Once we get a release out of the door and have some time, we will integrate the new filtering framework that will finally solve this bug.
  • We’re not sure if we manage to be able to migrate the IMAP cache if you’re using disconnected IMAP. That would mean re-downloading the mail again.
  • Probably IMAP server-side searching will not make it either

As said earlier, KMail is not yet ready for being released as a beta version. One major blockers right now is the lack of data migration, which includes reading the old KMail 1 index files and storing those flags in Akonadi, and also migrating over the account configuration. This is being worked on at the moment by Kevin Krammer, so we’ll have data migration before the first KDEPIM beta. The other blocker is the lack of client-side filtering, which Volker Krause is working on. As said above, that will at first be almost the same filtering system as we had in KMail 1, which allows us to have a working client-side filtering system for the first KMail 2 release. After those two blockers are fixed, which is before the first KDEPIM beta release, KMail 2 should be usable for other developers and testers, and we can concentrate on making KMail 2 usable for daily usage.

So the major changes in KMail 2 happen in the background, mainly not visible to the user, as the user interface largely stays the same. We have talked about the advantages of the Akonadi framework in other places, so I won’t repeat that here in detail. Overall, the porting to Akonadi is an important step in long-term stability and maintainability, and also fixes the old architectural issues we had with our 10-year-old system. I’m looking forward to the release of KMail 2 and of the ported version of KOrganizer and Kontact, which finally gives as a new architecture that meets modern requirements.

¹: No wonder I’m not blogging much, writing this blog took a long time 🙂




33 responses

14 05 2010

Did you discuss this with the KDE release team? From a user point of view I would suggest to delay the whole KDE release about a month.

And thanks a lot for your work on KDEPIM!

14 05 2010
Lindsay Mathieson

Sounds like a wise decision – better to delay a bit and no be rushed than have people freaking out and abusing you for releasing a beta to early.

The missing features won’t bother me at all – all my filters are server side on my imap server. Re downloading my cache for disconnected imap is no big deal, I think I’d rather do that than risk the possible flakeyness of trying to import it.

14 05 2010
Dion Moult

Well done! It’s great news to hear developers thinking from a user perspective and communicating their decision to delay it as an informed one.

Is the interface of other parts of Kontact (Korg, KAddressBook, KJots) changing visibly or will it also just be under the hood?

14 05 2010
Thomas McGuire

KOrganizer stays the same.
The KAddressbook UI already did change a lot in KDE 4.4, for 4.5 there will only be some minor UI improvements.
No idea about KJots.

3 06 2010
Sergei Naumov

That’s so weird, I still can not get Akonadi addressbook, and the entire akonadi for that matter, to work. 😦 It crashes all the time and I still use an “old fashioned” KIO data source. So, I thought, Kmail 2 will bring me joy…

14 05 2010
Stephen Kelly

KJots 4.5 will not visibly be very different, but will just use Akonadi under the hood.

In 4.6 it may take advantage of more Akonadi features.

KAddressBook is not changing very radically since 4.4, and KOrganizer is also not very different.

14 05 2010
Luca Beltrame

Thanks for the communication. I was a bit worried about the future of KMail 2: I’m glad you communicated your decisions (and I welcome the idea of delaying rather than “rolling back”: IMO KMail is *the* component that needs Akonadi).
As an extra question, will the KJots port and its plasma applet be included in the KDEPIM release?

14 05 2010
Stephen Kelly

Yes, it will be released with the rest of KDEPIM

14 05 2010

From distributors point of view I’m a little worried what to ship. Akonadi in KDE 4.4 caused lot of issues for us 😦 Wouldn’t be better to ship KMail 2 outside KDE 4.5 as technological preview for early adopters (as I understand testing in the wild is really needed!). It looks really very raw from your mail.

14 05 2010

This is an unfortunate solution, but definitely better than shipping an incomplete/unfinished version.

Though, I agree with Cheko that it would be cool if the whole KDE release could have followed suit. Unfortunately, I think it is too late now to talk about that since we are in a hard feature freeze…


p.s. Please send this announcement to kde-packagers list also.

14 05 2010
Luca Beltrame

@Ivan: According to the release-team ML, a delay of the SC release is also being considered.

14 05 2010
Alexander van Loon

Will the performance regressions caused by Akonadi also be fixed in this future release? I appreciate how Akonadi improves on searching through e-mails, but the loading bar appearing for a few seconds, saying ‘Starting Akonadi server’ when Kontact is started doesn’t leave a good impression. I get the idea Akonadi makes Kontact start slower, but will this improve?

14 05 2010

Any news on the Akregator port? Will it be ready for 4.5.1?

14 05 2010
Thomas McGuire

The Akregator port is not being worked on, it is still in the akonadi-ports branch. So the next KDEPIM release will contain the old Akregator.

14 05 2010

If most of the changes in KMail2 are going to be under the hood and invisible to the user, why release it before it has feature-parity with KMail1? If users can mostly see loss of functionality and not many new advantages to the move from KMail1 to Kmail2 you will get an outpour of complaints and trolling that KDE is repeating the KDE SC 4.0 mistakes all over again. Is there any reason why this should be pushed out during the KDE SC 4.5 cycle and not wait until 4.6? Am I missing something?

14 05 2010
Tobias Koenig

We have to release it with 4.5, because waiting for 4.6 won’t make it any better… without the pressure of actually getting something done, we might be tempted to work on something else, because since 4.6 release is sooooo long away.
And we can differ quite well now between users that are just trolling and those whole really wants to help us to improve KMail 😉

14 05 2010

Maybe simply not include KMail2 in 4.5.x? It would give enough time to solve all problems.

14 05 2010
New Package Blog, Controversy and KMail News for KDE 4.5 « Jmiahman’s Stuff

[…] been decided that the KDEPIM team will not release a new version till KDE 4.5 RC1 all of the Beta versions will be using KDEPIM from the 4.4.x series. Just thought I would let […]

14 05 2010
Alejandro Nova

As a KDE user, I say: please, delay one or two months the 4.5 SC. My reasons are:

1. KDE 4.4 is stable. We are not in the SC 4.0 era anymore; we can stand with 4.4, bugfix it and concentrate the bugfixing in Nepomuk and Akonadi. I miss point releases with minor features (like 3.5.8, 3.5.9), but I don’t mind if they don’t happen.

2. There are several amazing features that could be implemented and missing the boat, like additional KWin effects.

3. This alone justifies the delay: we are in the worst zone of the 6 month freeze. With KDE 4.4 we must wait two months for Ubuntu, three months for Fedora and four for Mandriva. So we are in the un-ideal situation that GNOME releases generate a climax, and we release on anticlimax, so, we reach silence. If we delay… we can begin a climax, and that will be good for KDE.

Please, save the good features, launch solid 4.4.5s or 4.4.6s with bugfixes and good-willed featurette backports and delay. Everyone will thank you for that in the long run.

14 05 2010
Luca Beltrame

“2. There are several amazing features that could be implemented and missing the boat, like additional KWin effects.”

Even if a delay has been proposed on the release-team ML, feature, API and so freezes would be still in effect if it is granted.

15 05 2010
Alejandro Nova

Didn’t know that, Luca. Thanks ;).

15 05 2010
Matt Parry

I agree with point 3

19 05 2010

In my opinion, one of the benefits to a release at this stage is having a point release (4.4.3) ready for consumption at the distribution level. Fewer bugs before the software is adopted at large sends a far better message.

15 05 2010

I agree with the opinion that it might be better if you delay the whole KDE SC 4.5 as such. And I would like to suggest something else: There are many waiting for it, as you said the most hated bug wont be fixed. So how about doing what other KDE-projects did: Make a fundraiser, which can pay someone, who helps bringing Kmail and I would also like to see this happen with Akregator, in shape. Of course, this would need someone qualified. But if you have someone in the team, who could do the extra work, if paid for, then please try it!

15 05 2010

Well this is interesting news. One question though: when are we going to see paragraph styles in kmail? (in order to make a word heading, a paragraph text body etc…)

17 05 2010

Hello, thanks for making kmail a great product 🙂
I just want to know if you already accept bugs for kmail2 or if it is too early ?
On one of my computers, I build and use kde trunk, so kdepim and kmail trunk.
I know that it is experimental sowftare and I test it on purpose.
I recently try to create a new gmail account (disconnected imap) from a clean config (removed all kmail* in KDEHOME, removed ~/.config/Akonadi)
The account was created successfully and I can select folders to suscribe in the akonadi resource configuration dialog. But kmail is “empty”, I don’t see my account in the main window.
These kind of bugs are expecteed at this point or should I fill a bug ?

20 05 2010
Thomas McGuire

IMAP should work already, so if it doesn’t, that is a bug, please report that.
But please try again with a newer version of SVN trunk, a lot changed there during the Akonadi meeting, so chances are that the bug is already fixed.
There are some expected bugs of course, but KMail should not be empty 🙂

For a clean config, you need to delete:
Where .kde4 may be .kde for you. Be careful, that will delete all your mails.

17 05 2010

I feel Kmail2 is going to face a lot of controversies. It’s not possible to ship both, ie, ship kmail and then ship kmail2 as an alternative software, or something like that?

7 06 2010
Fred Wells

Is the Kaddressbook/Akonadi mishap of 4.4 fame fixed regarding the missing Groups/Distribution Lists? This problem has held some back at 4.3, anxiously awaiting 4.5, which is now being pushed back another month. Some have moved on to Thunderbird, etc. due to the 4.4 release mistake. I’m holding out hope that I won’t have to abandon.

4 07 2010
Ernesto Manríquez

I’m testing now the fresh KDEPIM 4.5.0 beta 1 (released a little bit after KDE SC 4.5 RC1), and I must say, this is going to be good, but there are a lot of rough edges.

1. Mail has severe encoding problems.
2. I couldn’t successfully convert my KMail data into KMail2. It stopped around 25%
3. Akonadi IMAP engine is eating CPU for breakfast.

The main question right now is: HOW CAN I DEBUG THE THING AND BEGIN TO FILE SOME BUGS?. I want a great Kontact for KDE SC 4.5.1, and I’m willing to do my part to have it.

2 08 2010

“We’re not sure if we manage to be able to migrate the IMAP cache if you’re using disconnected IMAP. That would mean re-downloading the mail again.”

Or — as in my case, when the server has burned and the cache is all that remains, it would mean losing all of one’s old emails! I think this calls for a big warning in the release notes!

I have been moving my emails, a few at a time, from the cache to a new server: It is not possible to move too many at once due to this bug: https://bugs.kde.org/show_bug.cgi?id=219652

I was hoping for that bug to be gone in the Akonadi-based version, so that I could finish moving my emails, but instead I take it that I should get done with the job before upgrading to the new KMail?

2 08 2010
Thomas McGuire

Cache migration is implemented by now and should work, see also http://www.kdedevelopers.org/node/4241.

IMAP moves will hopefully be more efficient, yes (and if not, we have way more room for optimization with Akonadi compared to the old infrastructure)

17 08 2010
openSUSE News

[…] Thomas McGuire: Akonadi Meeting and the KDE SC 4.5 release […]

%d bloggers like this: