Hi! Another community goal aside from fixing up the chat software situation within KDE could be to either fix Akonadi or replace it by something that works…
Plasma and KDE Frameworks got a huge ton better in the last releases. But other parts of the KDE ecosystem appear to be mostly abandoned – like Kopete or KDE Telepathy – or in case they receive continuous development like with KDEPIM/Akonadi that continuous development does not seem to have achieved a stable, reliable and well performing solution for users in the recent years. Quite the contrary, with KDEPIM / Akonadi 20.04 it got worse. Just look at kdepim-users mailing list, on bugs.kde.org or on the internet. Since years many users are quite unhappy with the situation. Quite some abandoned KDEPIM after a lot of frustration with it. And I considered myself to abandon it way more than once as well, currently considering to switch to something else again. I was putting up with all the deficiencies, but recently it became quite unbearable for me as well as the situation for local maildir resources worsened considerably – Debian unstable / testing users are hit by this currently, I wonder why it wasn't reported before: Frustrating to use KMail with Akonadi 5.14.1 (20.04) https://mail.kde.org/pipermail/kdepim-users/2020-June/013315.html Thing is, while this regression is new, unreliability and performance issues regarding Akonadi are *known* for years. And capable developers spent a lot of effort to fix them. Yet… it still does not work. Some people even started over with the Kube project, but while the architecture of Sink that powers it appears to be more efficient and lean, Kube and Sink only provides a limited subset of the functionality users of KDEPIM use so far. The pity in there is: KMail and other KDEPIM applications are actually quite good. But especially KMail suffers a lot cause it waits for Akonadi to complete a request more often than not. It is a "wait for Akonadi game". The bug reports that describe why this is the case are open since years. I mentioned some of them in above post. I really mean no accusation here for anybody. I know KDEPIM and Akonadi developers are working hard. They are doing their best, I am sure of that. But while the situation intermittently improved some, it is still not really good. Also requiring users to be database administrators to make things work again in case of trouble… is simply a no go to me. Currently I have no idea how to fix the situation. I lack the C++ skills for it and while I can learn C++, in the situations I tried to understand how Akonadi works and where I find what in the code… where I would even start looking about fixing a certain issues… I failed. I know some of how it works, but I never brought it all together. I may be able to learn all of this, but given that even seasoned KDEPIM developers have not been able to really stabilize Akonadi… I feel that the bar is quite high. The bugs that cause the trouble are all reported on bugs.kde.org – many for years already. Again no offense meant. The KDEPIM developers do what they can. At the same time more and more new cool features are developed for Akonadi and KDEPIM like KDE Itinerary or Etesync this. But the foundation still is not as solid as it would need to be for users to have a more pleasant experience with it than many users currently have. It works for some, sure… but just look at the mailing list, the bug tracker and on the internet… many users struggle with it. Including myself… and I defended Akonadi before quite a bit before, despite all the trouble I had with it. I am not defending it now. It is still not working reliably, it still does not perform well for a considerable amount of users. Anyone having any idea how to improve this situation? Could it help to make fixing this up one of the next community goals? I know it is some time till the current 3-year period for goal achievement is completed. What else could help? Best, -- Martin
