[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

KDEPIM issues (was: Re: Bugs bugs bugs)



Hi Volker,

Am Samstag, 21. Februar 2015, 16:32:33 schrieb Volker Wysk:
> Am Samstag, 21. Februar 2015, 00:15:29 schrieb Martin Steigerwald:
> > Am Montag, 16. Februar 2015, 09:05:38 schrieb Volker Wysk:
> > > Hello!
> > 
> > Hi Volker,
> > 
> > > Actually, I'm a KDE fan. But it - still - has that many bugs, that I
> > > couldn't recommend it.
> > > 
> > > "Still" means 4.14.2, the version in Debian-unstable. Does anybody
> > > know
> > > when KDE5 will arrive in Debian? Or has even tried it?
> > > 
> > > I've tried to compile KDE from the sources, but failed.
> > 
> > Maxy uploads a lot of KDE Frameworks 5.6 and Plasma 5 packages into
> > Debian experimental since quite some weeks. It seems they are not yet
> > build to binary packages tough. I bet we will read about it when they
> > are ready.
> > 
> > Maxy also uploaded some 4.14.5 packages, I think for KDEPIM, to
> > experimental as well. I think 4.14.5 packages would be good for stable
> > as well, but well…
> 
> Sounds good.
> 
> I've never used the experimental branch. When will the packages migrate
> to Unstable?

They won´t before Jessie release.

Maybe KDEPIM 4.14.5 could make it to unstable as its only bug fixes, but 
that would need an exception from the release team as well in this late 
state of Jessie freeze, I think – unless they fix RC bugs (and only! them). 
The freezing / release policy is clarified in some document I don´t have 
the URL at hand at the moment, should be easy to find.

> > For me beside KDEPIM KDE / Plasma 4.14.2 really works quite good.
> > KDEPIM basically works, but there are still a lot of open issues.
> 
> Exactly...

Well, that may not change *that much* with a newer version. 4.14.5 has 
some bugs fixed, but I compiled kdepim-runtime and kdepimlibs 4.14.5 on top 
of KDEPIM 4.14.2 as packages by debian and I still have most of the 
issues. I also run akonadiserver 1.13 branch from git with the MySQL 
optimizations, and while that helps with MySQL load, I still have KMail 
and Akonadi seem to disconnect with each other at times.

And the Plasma 5 / Qt 5 port of KDEPIM is not yet ready as far as I am 
aware of. Even that will use the Akonadi as we now it today, so it may 
have still similar shortcomings and bugs.

There is Akonadi Next in prototyping by Aaron Seigo and Christian 
Mollekopf, but this is far from finished so far.

So I think there are no updates available to KDEPIM and Akonadi at the 
moment that will fix those longer existing issues. So I think if you want 
to be without those bugs *now*, you can only use a different set of 
applications or try to fix the bugs yourself or get someone paid to do it.

I am not sure whether all the fixes for the KDEPIM deployment in Munich 
have gone upstream. I had hoped that these would fix quite some of the 
longer term issues of Akonadi, but whatever trickled upstream so far did 
not seem to fix it.

I sure hope that KDEPIM and Akonadi is performaning better in the Munich 
setup than for me personally. I still use POP3 for my main private 
account, but also IMAP is fragile, with Exchange, but there Exchange has 
at least a fair share in causing the trouble.

What could work quite well, and thats why I think for Munich it could 
work, would be to have some decent (!) IMAP server like Dovecot (not 
Exchange!) together with KMail.


So while for me KDEPIM and Akonadi got a lot better, like Nepomuk got, 
before Vishesh replaced it by Baloo which works even better, KDEPIM and I 
think especially Akonadi still has a fair share of issues. I think the 
majority of the bugs I reported for KDE / Plasma in the last 2 or 3 years 
with bugs.kde.org has been with Akonadi and KDEPIM.

Yet, reporting those won´t magically make them go away and upstream could 
need more developers. Thats why I hope that the adoption of KDEPIM for 
Munich will help its overall stability. Cause frankly, from what I see so 
far, it is not enterprise ready at all. But consider, with Kolab using a 
decent IMAP server (and it does to my knowledge, especially if Dovecot is 
used) and smaller accounts than I have, it may well work okay. And I have 
seen slides that a ton of data has been migrated to it and it works okay. 
So this is just my personal impression that I draw from my three setups I 
have and in no way representative. I read less about serious issues in 
kdepim-users these days. Whether that means they have gone away for some 
users or the users just silently put up with it or use something different, 
I don´t know.

So for a clearly defined setup where you control server and client I think 
for IMAP it can work okay. Not excellent, but okay.

KDEPIM / Akonadi I think still needs robustness work. But someone has to 
do it. And unless I actually contribute to that, I know I need to wait 
until someone does.

I still think KMail is simply the best MUA for desktops I have *ever* 
seen. So I put up with any issues, fine tuning my setup with some tricks I 
learned recently (SizeTreshold=32768, was mentioned here on list and I 
also mentioned it on kdepim-users), and try to be patient, while compiling 
updated versions from source, as I explained how to do as well.

In case you want to go that route, I suggest you also subscribe to kdepim-
users and probably kde-pim upstream mailinglists via lists.kde.org and be 
prepared to deal with any issues you see, report bugs, help with bug 
triaging and try to be patient.

Thats the situation as I see it today after having myself investing quite 
some time into bug reporting, reading up bugs, trying to fix things for me 
without going into developing. Doing that might be the next step, but from 
the performance fix for Maildir´s KDEPIM devels guided me to some time ago 
I got the impression that the Akonadi code base wants some time to 
understand it enough to fix any of the longer term, in my eyes, probably 
fundamental, issues with it.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


Reply to: