Rex Dieter wrote:

Given these new developments, I've untagged this from rawhide, and removed the builds from kde-unstable for now... pending further discussion and planning.

I guess I jumped the gun. I stumbled upon it this morning and installed it.

Migration went smoothly (no glitches with kwallet, emails or mail providers). Ok, there was one minor problem: I had to change the ownership of kmail2rc from root:root to me:me to make the file read/writeable.

I can receive/read emails and everything appears to work (fonts are smaller than they were previously). I haven't tried sending an email yet, admittedly. Otherwise, it doesn't really appear any different, except that now the mail transports are in akonadi.

On Wednesday 07 July 2010 02:30:29 Rex Dieter wrote:

Given these new developments, I've untagged this from rawhide, and removed the builds from kde-unstable for now... pending further discussion and planning.

I hope, you're shipping KAddressbook 4.5 with F14. It was already migrated to Akonadi with SC 4.4, but the 4.4 release has a few regressions, like missing multiple "Instant Messaging" address fields.

Markus

Arthur Pemberton wrote:

Why does it seem that KDE PIM in general was given a much lower priority in the the move to KDE 4, as opposed to things like KWin, and Plasma?

Because it was? ;-)

Akonadi was supposed to be one of the "pillars of KDE 4" right from the start (i.e. 4.0). But while most other components of KDE 4 released ports to the new technology with 4.0 even when it was far from ready, leading to the most buggy KDE ever, kdepim, after missing 4.0 entirely due to the apps not being ported in time because everyone was waiting for Akonadi, decided to complete the ports for 4.1 as straight ports of the KDE 3 versions, with very few changes.

Even application-level changes such as new MVC-based list views for KMail were postponed away from 4.1 and came only in later 4.x releases. On one hand, this allowed making kdepim 4.1 a very stable release and pretty much a drop-in replacement for 3.5, but on the other hand, this meant Akonadi was still stuck in the future and with no obvious place and time to introduce it.

The kdepim team then tried again and again to gradually phase in Akonadi: in 4.2 and 4.3, each time they were trying to tell us "Akonadi is now a core part of KDE, make sure you make it work by default", but each time it turned out to be optional and not used by much if anything. (Well, KPilot started using it soon, but if you don't own a Palm, you don't care about that at all.) Then, in 4.4, we finally got 1 (ONE!) of the core kdepim apps using Akonadi, namely KAddressBook, but none of the other Akonadi ports were ready in time.

Enter 4.5. By now, the rest of KDE is entering or has already entered a phase of stability, with the rate of change slowing down and the maturity and reliability going up; kdepim, on the other hand, still has the big transition they were supposed to provide with 4.0 pending, so the kdepim team decided to finally bite the bullet with 4.5 (after they missed the merge window for 4.4). So they merged the Akonadi branch of all of kdepim into the trunk wholesale soon after 4.4 branched, when it was clearly not releasable yet, hoping to complete the work on the trunk. What happened as a result is that the trunk, and now the 4.5 branch as well, ended up in an unstable state and will now not be releasable as a stable release with KDE 4.5.0, and since this all happened in the trunk, not a development branch, there was no good plan B. (The only thing they could have done is overwriting the stuff with the 4.4 branch, throwing out all the 4.5 development entirely.)

The way I, as an observer, see the problem is twofold: the changes are way too ambitious, and they're being implemented too slowly. The amount of planned changes does not fit the rate of development at all. Thus, we end up with something that's 6 releases, i.e. 3 years, late compared to the already heavily delayed KDE 4.0, and with a destabilizing major change being shoehorned into a KDE where the global trend has already been stabilization for a while.

I personally think Akonadi should have been postponed to a possible KDE 5 or scrapped entirely, but I also see the limitations of the "change as little as possible" approach: Kompare was ported that way (by me), so it suffered very few regressions, but it also still has most of the same bugs the KDE 3 version had, almost no new features and it's still using *3support legacy crap (which is now finally being ported away from, but those changes also caused 2 regressions which are now fixed and maybe more which we're yet to discover, and there's still *3support usage left). On the other hand, some of the rewritten stuff everyone including me has been complaining about is now working really well and has surpassed the KDE 3 version (whereas other stuff still leaves much to be desired, rewriting requires a lot of effort to get right).

Disclaimer: This is how I recall the history. I am not a kdepim developer, and one or the other detail might be inaccurate. Please take all the above with a grain of salt.

Another disclaimer: In the above, "KDE" refers to the software compilation released by the KDE project. Feel free to call it "KDE SC" or whatever new thing the KDE project's marketing people think of next. ;-) Any complaints about naming will be IGNORED.

Kevin Kofler