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
_______________________________________________
kde mailing list
kde@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kde
New to KDE4? - get help from http://userbase.kde.org
