[Kde-pim] KDEPIM 4.5 releases

Kevin Kofler kevin.kofler at chello.at
Wed Jul 7 04:10:57 UTC 2010


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



More information about the kde mailing list