Showing respect (was: Re: The KDEPIM / Akonadi situation)

Martin Steigerwald martin at lichtvoll.de
Fri Jun 12 21:38:11 BST 2020


I am, for this time, cc'ing again to KDEPIM development mailing list as 
I did in my initial mail, just to raise the awareness that the 
discussion continued on the community mailing list. I did not add the 
cc'd back on answers by others that did not keep the cc assuming KDEPIM 
developers would likely also be subscribed here, but in the end that is 
just an assumption.


Friedrich W. H. Kossebau - 12.06.20, 15:04:34 CEST:
> Please, let us keep this a community working together, not against
> each other, and one showing respect to each others efforts. All of
> Plasma, KDEPIM, KDevelop etc. pp. have lots of issues. We could be
> bitching about each others products all day long and where their
> developers have not instantly cared

Again, I have lots of respect for KDEPIM developers. For a long time I 
wrote long mails to defend Akonadi and KDEPIM against what in part out 
of frustrations in my eyes often were really quite rude mails.

For me this is not *at all* directed against the KDEPIM developers. I 
cc'd the KDEPIM development list in my initial mail for a reason. I did 
not cc again as I saw answers were mostly not cc'd to it as I thought 
KDEPIM developers are likely to also be subscribed to kde-community 
mailing list. It is by *no way* meant personal. And people who know past 
mails from me can actually *know* that. I wrote lengthy mails to defend 
Akonadi and did what I can, with the talents I had had hand at that 
time, to help to improve the situation.

My call now is to see what can be done to improve the situation. If that 
was not clear from my initial mail, here you have it.

I do not have an answer. But I do believe that this is neither about 
being paid or not paid development work – also AFAIK there has been paid 
KDEPIM work as well for quite some time. Nor, again, it is about the 
skills of the involved developers. KDEPIM developers are all much more 
proficient with C++, Qt and KDE stuff than me. And I *admire* them for 
their dedication.

For me part of the answer meanwhile is: It appears to be pretty damn 
hard to get Akonadi right. Simple as that. Whether that is due to its 
architecture or other reasons I don't really know, but I believe the 
architecture of Akonadi to be a part of the answer.

Cause frankly, when I truly think what a suite of PIM applications mean 
to me with a user hat on, I'd say something like "akonadictl fsck" is a 
bug already. Seriously, fsck my mail program? If I truly think this 
through I have *no* idea how to explain this to someone who just wants 
to use it. Never ever in my whole live I fsck'd a PIM application 
before.

It is by *no way* disrespectful to point that out. If that would be 
considered  disrespectful to me it appears that criticism is not allowed 
here anymore.

Never ever it was my intention to hurt anyone or make it personal. And I 
strongly object any attempt to make some "against each other" out of my 
attempt to raise an issue and see whether there could be some way of 
support for the KDEPIM developers to improve the situation.

I am even in for fundraiser like in Krita. We even had been there 
already, years ago. I still recall the discussions where users offered 
support to fund some of the development. However the answer I got from 
KDEPIM developers back then was that this would not help. Basically I 
got back that KDEPIM developers who understand enough of Akonadi 
*already* have a day job. In that case paying one of them for some time 
would need some agreement by their employer to set them free for that 
time with a guarantee that their day job is still there after that time. 
I am not putting names here, as again, I am not intending to make any of 
this personal.

For the current regression in maildir resource I am meanwhile even 
willing to step up to make a good attempt to find what is causing it, but 
I know I would need help and support for doing so. And I know fixing the 
regression would not fix all the other serious stability, reliability and 
performance issues.

I am open to any good answers, how this situation can be improved and 
ideally I would like to see KDEPIM developers speak out about it as 
well:

What would help you? What does it take to considerably improve the 
situation within a time frame that could end the frustration for users 
and through the frustration of users also for developers soon at least 
to a great degree?

I believe raising this to a broader audience may invite answers that 
within the KDEPIM project no one did think of.

PS: I may stop to respond in case I see my attempt to raise this issue 
to a wider audience in order to find ways to improve upon it is not 
moving in a beneficial direction. I did my best to make my intention 
clear, if people do not pick it up and instead try to make an "against 
KDEPIM developers" out of it… it may be better to end the discussion 
already. I cannot control how others react to what I write. So if 
despite my best efforts to word it as clearly as I could this does not 
move in a direction that is beneficial to KDEPIM, there is no need to 
continue this.

Raising this issue is by no way disrespectful. I stand by this.

Best,
-- 
Martin





More information about the kde-community mailing list