Re: KDEPIM issues (was: Re: Bugs bugs bugs)
Hey,
> 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.
It is quite hard to track issues down, if they happen once in a while. I think
all kdepim devs so am I try to fix these stuff, but hunting anything non
reproducable is a lot of work.
> 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.
The porting work for qt5 is done in master - but we won't release it until the
new api for akonadi next is outlined. We do not want to stick another release
cycle with the current api for akonadi. The current plan is to release in a
year. Until than only bugfixes are released for the qt4 version.
> 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.
Neither the bugfixes nor enhancment havn't got upstream - they are only
available at github and on our obs:
https://github.com/kolab-groupware/kdepim
https://obs.kolabsys.com/project/show/Kontact:4.13:Development
Well hopefully the next weeks give us time to push things upstream.
> 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.
kolab uses cycrus as imap server. But dovecot ( I use this personaly) also
plays very nicely with kmail.
> 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.
Well akonadi was the first try of such a middelware and we learned a lot of
things. And we now know, that was bad/good design descisions, these we went
into akonadi next.
> 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.
cewl - I'm looking forward to see more of your work in kdepim; if there is
anything where I can assist you - feel free to contact me.
regards,
sandro
Reply to: