Re: The KDEPIM / Akonadi situation
Hi! As it is important to be fair and open what could have been a effect of an unusual combination of software versions in Debian at that time: Martin Steigerwald - 11.06.20, 11:50:53 CEST: > 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… […] > Frustrating to use KMail with Akonadi 5.14.1 (20.04) > > https://mail.kde.org/pipermail/kdepim-users/2020-June/013315.html What was the most frustrating about all of this was a regression with Akonadi 20.04 in Debian back then: [Akonadi] [Bug 422336] kmail: the access and reading of the received messages is often very slow https://bugs.kde.org/422336 I still do not know what caused it and how it got fixed. But with Qt 5.14.2 (instead of the former Qt 5.12 in Debian) and probably other updates in Debian this regression is gone. Synchronizing mail folders is much, much faster again. To the extent that despite all the other issues that are still unreleased KMail is basically usable again. Thanks to everyone who may have been involved in the fix. Maybe… it was that Akonadi 20.04 did not like Qt 5.12 or maybe it was whatever… I am not sure what the Qt minimum version for Akonadi 20.04 is… but I would bet that our Debian packagers respected it. I did not follow up on recent mails on the thread, cause I had the impression that my initial mail did not achieve what I intended to achieve with it – except for one guy offering to help development of KDEPIM and Akonadi! Well which is quite something… if I consider it! Also while I still think "akonadictl fsck" is a thing a user should never have to deal with… – no Outlook is not a reference for me and Evolution, Thunderbird and others do not have anything like that as far as I am aware, also Firefox does not have it for its countless SQLite databases, … – it is only one aspect of what I brought up and I saw no benefit in discussing that out to the end. The other issues I mentioned remain, but are not as severe now that the dire performance regression has disappeared. I remain with the best wishes for the KDEPIM team and hope that some day even those who felt hurt after reading my mail can understand that in no way I meant it personal. What I was going for was to find ways to support the KDEPIM project, but it appears that the frustration I experienced did not really help to achieve that goal. So if there are any hurt feelings left… I apologize. It was never my intention to hurt anyone. That all written I also stand with my assertion that the other issues I mentioned are all still there and the KDEPIM project IMHO can really benefit from some community support or setting improving it as a goal on the next goal round. I also still assert that no mail of mine in this thread has been disrespectful to the KDEPIM developers. Maybe one day there can be a constructive discussion about how to support the KDEPIM project. For now I let it sit as it is. Best, -- Martin
Rectification/completion (Re: The KDEPIM / Akonadi situation)
Hi again, Le 2020-06-28 à 09:49, Philippe Cloutier a écrit : Hi Martin, Le 2020-06-12 à 16:49, Martin Steigerwald a écrit : [...] That being said, I am not saying KDEPIM (widely speaking) can't be improved. I personally gave up on KMail more a decade ago after seeing enough reports of serious issues and experiencing so many issues myself that I haven't even been tempted enough to give it a new try yet. And nevertheless, I still have serious issues with all KDEPIM applications I still use, i.e. KNotes and KOrganizer. One which may be related to Akonadi was reported years ago. I reported quite a few more last year, even largely providing the solution to some, but in all cases, to my knowledge there was no progress, even though I mentioned some of these issues in messages sent to this very list, most recently https://mail.kde.org/pipermail/kde-community/2019q4/005921.html I don't know if this was a coincidence or if my mail prompted it, but I must report receiving a mail whose news and tone I both appreciated much today: https://marc.info/?l=kde-devel=159344847927458=2 It turns out that a few days after this thread begun, Glen Ditchfield prepared a fix for one of the core issues affecting KOrganizer I was referring to yesterday, and that fix looks great. Thank you very much for making me wrong*, Glen. That being said, if things go very well from here, it will still have taken more than a year after the problem was explained to ship a solution. And looking at Glen's work made me realize English Canada was also affected, which means for some time KOrganizer would have been largely broken for almost all Canadians. And we would have apparently received at least 6 more reports in due form of the problem, the first one in March 2019. So in the end, this certainly doesn't change anything about Akonadi, and can't help much with my perception of KDEPIM's state. [...] [...] * almost -- Philippe Cloutier http://www.philippecloutier.com
The KDEPIM / Akonadi situation (was: Re: Showing respect)
Hi Martin, Le 2020-06-12 à 16:49, Martin Steigerwald a écrit : [...] 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. I wasn't aware of akonadictl fsck. Thanks for pointing that, and I understand very well what you mean, but my experience/misfortune forces me to dispute this point. Even the most famous (and probably most funded) PIM software has an equivalent called SCANPST, and it is actually required in my experience. I had to use it with Outlook 2003 hundreds of times, and it's not gone in the newest versions. And despite its name, it's also relevant for the newer file format (OST): https://support.microsoft.com/en-us/office/repair-outlook-data-files-pst-and-ost-25663bc3-11ec-4412-86c4-60458afc5253?ui=en-us=en-us=us So without saying there is no room for improvement there, we can't really single out Akonadi just for that. I researched the topic a bit and according to what I see on Wikipedia, NTFS would be the only filesystem to feature transactions: https://en.wikipedia.org/wiki/File_system#Transactional_file_systems Plus, the feature is deprecated, so I'm afraid filesystem integrity will remain problematic for quite some time: https://en.wikipedia.org/wiki/Transactional_NTFS That being said, I am not saying KDEPIM (widely speaking) can't be improved. I personally gave up on KMail more a decade ago after seeing enough reports of serious issues and experiencing so many issues myself that I haven't even been tempted enough to give it a new try yet. And nevertheless, I still have serious issues with all KDEPIM applications I still use, i.e. KNotes and KOrganizer. One which may be related to Akonadi was reported years ago. I reported quite a few more last year, even largely providing the solution to some, but in all cases, to my knowledge there was no progress, even though I mentioned some of these issues in messages sent to this very list, most recently https://mail.kde.org/pipermail/kde-community/2019q4/005921.html I don't know much about community goals and what setting one entails. "Fixing KDEPIM / Akonadi" doesn't sound like a low-hanging fruit, but that doesn't mean the benefit–cost ratio wouldn't be high. I have no clue about Akonadi's architecture and don't know much about it in general. I don't know if Akonadi should be rewritten, but if it should (and that's a big "if"), I would agree with prioritizing that over writing a new sound player, a new text editor or a new window manager. I don't know if this should be a community goal, but I think properly tracking KDEPIM / Akonadi issues would be a good start (achievable for much cheaper than rewriting Akonadi) making it easier to decide whether a rewrite is needed and to what degree such a goal should be prioritized. [...] -- Philippe Cloutier http://www.philippecloutier.com
Re: The KDEPIM / Akonadi situation
On Sun, Jun 14, 2020 at 4:29 AM Ingo Klöcker wrote: > > On Samstag, 13. Juni 2020 10:35:50 CEST Ben Cooksley wrote: > > There is nothing that can be done to delay builds for one repository > > on the build of another at this present time. > > Neither Jenkins or Gitlab CI provide the necessary support for us to > > link jobs together in the way that PIM demands in this case here. > > > [snip] > > > > In terms of Gitlab, while it does allow triggering jobs in other > > projects as part of a job run (see > > Minor correction: It does allow triggered pipelines in other projects. > > > https://docs.gitlab.com/ee/ci/multi_project_pipelines.html) this is > > limited to a dependency chain only. > > Not sure what you mean by "a dependency chain only". I have implemented > dependency trees even with loops (and then taking care that they don't loop > too often) in GitLab. What has not been possible was to prevent pipelines from > being triggered too often in diamond shape dependency scenarios. By "dependency chain only" what I mean is that we don't want it to waterfall down. A change in KCoreAddons should not cause most of Frameworks followed by all of Plasma/Release Service/Extragear to be rebuilt. Providing CI would become impossible in that case, as it takes many hours (something on the order of 24+ hours) for the CI system to rebuild everything for all platforms. > > > It does not extend to waiting for the parent job to complete. > > That doesn't matter if the job triggering the pipeline of the dependent > project is the last job (i.e. in the last stage) of the parent project's > pipeline. It does matter, because that is what Christophe was asking about. It is also the only scalable option. > > Regards, > Ingo Cheers, Ben
Re: The KDEPIM / Akonadi situation
On Sun, Jun 14, 2020 at 3:35 AM Adriaan de Groot wrote: > > On Saturday, 13 June 2020 09:29:36 CEST Volker Krause wrote: > > I have finite time and prioritized what seemed to have most wide-spread > > impact (all of Android and all of Flatpak vs. Akonadi/FreeBSD), > > And, as time and circumstance permits, the PIM team prods me and/or tcberner > to take an extra close look. > > > > There is a peculiar cascade going on here, which **isn't** especially PIM- > related. > > 1) kaccounts-integration has a binary-incompatible change going on: it changed > to > explicit GetCredentialsJob(Accounts::AccountId id, QObject *parent = > nullptr); > > from > > explicit GetCredentialsJob(const Accounts::AccountId , QObject > *parent = nullptr); > > 2) For whatever reason, **older** kaccounts-integration is installed on the > FreeBSD builders before Akonadi builds; this puts the old headers in /usr/ > local/include This should be removed (along with any Frameworks and other associated KDE code) As a general rule, CI builders are supposed to be sterile machines, having nothing that they build installed on them to ensure the environment is pure to avoid contamination from older versions of our software which causes unexpected failures. (In essence, the goal is to replicate the sort of environment that would be used by packagers, or those setting their system up for the very first time as much as possible) > > 3) I don't know if new accounts-integration builds before Akonadi; if it does, > I don't know where it is installing its headers. The CI system supplies kaccounts-integration as part of the dependencies it fetches, which are the results from prior builds. This can be seen at https://build.kde.org/job/Applications/job/akonadi/job/kf5-qt5%20FreeBSDQt5.14/lastSuccessfulBuild/consoleText In this log we see "Retrieving: Applications-kaccounts-integration-kf5-qt5" which is where it fetches and makes kaccounts-integration available. The list of projects that are fetched and made available to a project when building is governed by the metadata files in sysadmin/kde-build-metadata on invent.kde.org. In terms of where it gets installed to, this is specified by the --installTo parameter to prepare-dependencies.py, which is set to /home/jenkins/install-prefix/ in that log. Following the completion of the build (regardless of failure or success) that directory is erased to ensure the system has a clean state for the next build that runs on the machine. We are forced to use a single path that is identical for all builds due to limitations in KWin and it's associated components, which for "security reasons" bake the install path into their binaries, something that makes them non-relocatable. If this path is changed, then KWin's tests fail. > > 4) When building Akonadi, it has /usr/local/include in its search path > **ahead** of any paths that might point to the "new" accounts-integration > headers. So it picks up the old definitions, then bails out when it tries to > link to the new libraries. > > > > I can reproduce the problem locally with kdesrc-build. > > Possibly Linux CI doesn't get the same problem, because it doesn't need to > have extra system header locations (i.e. /usr/local/include) put onto the > search path, and so an older installed accounts-integration just lives in the > "default bits" which are searched last. > Linux and Windows CI won't experience this issue as their environments are sterile, and don't contain any KDE software until it is brought in (and subsequently cleaned up following a build) by the CI system. > > So if anything, what we're seeing here is a BIC that falls over because too > many pieces have to move at once, on a platform that has some special > considerations, that none of the PIM developers are on all the time. If you > want to get on their case at all, do it for "ask [ade] or tcberner earlier", > although in this particular case it wouldn't have sped things up: it's > saturday afternoon, and now I have time to look into this. > > [ade] > Cheers, Ben
Re: The KDEPIM / Akonadi situation
On Saturday, 13 June 2020 18:21:24 CEST Volker Krause wrote: > Thanks Ade! It looked like Dan had fixed the build error this morning > though, I see things being green here: > https://build.kde.org/job/Applications/view/ > Everything/job/akonadi/job/kf5-qt5%20FreeBSDQt5.14/ - where did I miss the > Accounts issue? I guess it's all good then. I can't build (as in "the build fails") Akonadi in a dirty environment (as in "with older frameworks and pim bits installed"), but with enough goes-round, or a clean environment, it's good. Anyway, don't hesitate to tug at my sleeve in #kde-devel. [ade] signature.asc Description: This is a digitally signed message part.
Re: The KDEPIM / Akonadi situation
On Samstag, 13. Juni 2020 10:35:50 CEST Ben Cooksley wrote: > There is nothing that can be done to delay builds for one repository > on the build of another at this present time. > Neither Jenkins or Gitlab CI provide the necessary support for us to > link jobs together in the way that PIM demands in this case here. > [snip] > > In terms of Gitlab, while it does allow triggering jobs in other > projects as part of a job run (see Minor correction: It does allow triggered pipelines in other projects. > https://docs.gitlab.com/ee/ci/multi_project_pipelines.html) this is > limited to a dependency chain only. Not sure what you mean by "a dependency chain only". I have implemented dependency trees even with loops (and then taking care that they don't loop too often) in GitLab. What has not been possible was to prevent pipelines from being triggered too often in diamond shape dependency scenarios. > It does not extend to waiting for the parent job to complete. That doesn't matter if the job triggering the pipeline of the dependent project is the last job (i.e. in the last stage) of the parent project's pipeline. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: The KDEPIM / Akonadi situation
On Saturday, 13 June 2020 17:35:08 CEST Adriaan de Groot wrote: > On Saturday, 13 June 2020 09:29:36 CEST Volker Krause wrote: > > I have finite time and prioritized what seemed to have most wide-spread > > impact (all of Android and all of Flatpak vs. Akonadi/FreeBSD), > > And, as time and circumstance permits, the PIM team prods me and/or tcberner > to take an extra close look. > > > > There is a peculiar cascade going on here, which **isn't** especially PIM- > related. > > 1) kaccounts-integration has a binary-incompatible change going on: it > changed to > explicit GetCredentialsJob(Accounts::AccountId id, QObject *parent = > nullptr); > > from > > explicit GetCredentialsJob(const Accounts::AccountId , QObject > *parent = nullptr); > > 2) For whatever reason, **older** kaccounts-integration is installed on the > FreeBSD builders before Akonadi builds; this puts the old headers in /usr/ > local/include > > 3) I don't know if new accounts-integration builds before Akonadi; if it > does, I don't know where it is installing its headers. > > 4) When building Akonadi, it has /usr/local/include in its search path > **ahead** of any paths that might point to the "new" accounts-integration > headers. So it picks up the old definitions, then bails out when it tries to > link to the new libraries. > > > > I can reproduce the problem locally with kdesrc-build. > > Possibly Linux CI doesn't get the same problem, because it doesn't need to > have extra system header locations (i.e. /usr/local/include) put onto the > search path, and so an older installed accounts-integration just lives in > the "default bits" which are searched last. > > > So if anything, what we're seeing here is a BIC that falls over because too > many pieces have to move at once, on a platform that has some special > considerations, that none of the PIM developers are on all the time. If you > want to get on their case at all, do it for "ask [ade] or tcberner earlier", > although in this particular case it wouldn't have sped things up: it's > saturday afternoon, and now I have time to look into this. Thanks Ade! It looked like Dan had fixed the build error this morning though, I see things being green here: https://build.kde.org/job/Applications/view/ Everything/job/akonadi/job/kf5-qt5%20FreeBSDQt5.14/ - where did I miss the Accounts issue? Regards, Volker
Re: The KDEPIM / Akonadi situation
On Saturday, 13 June 2020 09:29:36 CEST Volker Krause wrote: > I have finite time and prioritized what seemed to have most wide-spread > impact (all of Android and all of Flatpak vs. Akonadi/FreeBSD), And, as time and circumstance permits, the PIM team prods me and/or tcberner to take an extra close look. There is a peculiar cascade going on here, which **isn't** especially PIM- related. 1) kaccounts-integration has a binary-incompatible change going on: it changed to explicit GetCredentialsJob(Accounts::AccountId id, QObject *parent = nullptr); from explicit GetCredentialsJob(const Accounts::AccountId , QObject *parent = nullptr); 2) For whatever reason, **older** kaccounts-integration is installed on the FreeBSD builders before Akonadi builds; this puts the old headers in /usr/ local/include 3) I don't know if new accounts-integration builds before Akonadi; if it does, I don't know where it is installing its headers. 4) When building Akonadi, it has /usr/local/include in its search path **ahead** of any paths that might point to the "new" accounts-integration headers. So it picks up the old definitions, then bails out when it tries to link to the new libraries. I can reproduce the problem locally with kdesrc-build. Possibly Linux CI doesn't get the same problem, because it doesn't need to have extra system header locations (i.e. /usr/local/include) put onto the search path, and so an older installed accounts-integration just lives in the "default bits" which are searched last. So if anything, what we're seeing here is a BIC that falls over because too many pieces have to move at once, on a platform that has some special considerations, that none of the PIM developers are on all the time. If you want to get on their case at all, do it for "ask [ade] or tcberner earlier", although in this particular case it wouldn't have sped things up: it's saturday afternoon, and now I have time to look into this. [ade] signature.asc Description: This is a digitally signed message part.
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
Hello, On Friday, 12 June 2020 20:47:55 CEST Carl Schwan wrote: > Le vendredi, juin 12, 2020 1:45 PM, Kevin Ottens a écrit : > > Incidentally it's been the top discussion topics for the past few KDEPIM > > sprints. And also during BoFs at Akademy. I even think there's been > > discussions about that on the pim list and IRC channels. > > And I think the PIM team did a lot of good work in this direction, there is > documentation on how to build the PIM libs and apps, a big list of junior > jobs with that in my experience get active mentoring when someone wants to > claim one of them. > > Could the PIM team make the whole onboarding process easier? Probably but it > would also impact the limited time the PIM devs have to work on the PIM > apps. But in my opinion that makes it very hard to get more devs working on > the PIM apps is that this is a complex system and that it is not the cool > new tech but instead, deals with tons of legacy systems. If someone wants > to help the PIM team, I would recommend taking one of the junior jobs or > updating the documentation related to PIM on the wikis. Thanks. This is exactly why I send my email. Thing is more people are needed, the tiny team around KDEPIM did everything it could to attract said people and we can't say many hands showed up so far. > If I remember correctly I got my KDE developer account with the support of > Laurent after completing one of the Junior Job, so merci beaucoup Laurent > and the rest of the team for making me discover the KDE community. Didn't get a chance to say it earlier, but I'll use the opportunity: I'm glad we have you on board. :-) Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: The KDEPIM / Akonadi situation
On vendredi 12 juin 2020 23:54:19 CEST Ben Cooksley wrote: > They are however, terrible at reading emails from the CI system. To the > point I suspect they have filters sending such mail to the trash so it is > never seen. > > Akonadi has been in a broken state for several days now on FreeBSD. They > have received multiple notices of this to their mailing list, and yet no > action has been taken. > On samedi 13 juin 2020 09:29:36 CEST Volker Krause wrote: > sigh, not this again please... Ben, you very well know I look after Jenkins > issues at least once a day. Here's yesterday: > (1) manually triggered a number of PIM builds that were stuck due to having > ran in the wrong order, I'm sure the Jenkins log will confirm that if you > don't believe me. Now here's my question to sysadmins: Failures caused by the testing system being unable to build things in order has *always* being present and doesn't only concerns the pim repositories. What did you do to fix the repeated failures caused by systems you maintain?
Re: The KDEPIM / Akonadi situation
On Sat, Jun 13, 2020 at 7:52 PM Christophe Giboudeaux wrote: > > On vendredi 12 juin 2020 23:54:19 CEST Ben Cooksley wrote: > > > They are however, terrible at reading emails from the CI system. To the > > point I suspect they have filters sending such mail to the trash so it is > > never seen. > > > > Akonadi has been in a broken state for several days now on FreeBSD. They > > have received multiple notices of this to their mailing list, and yet no > > action has been taken. > > > > On samedi 13 juin 2020 09:29:36 CEST Volker Krause wrote: > > > sigh, not this again please... Ben, you very well know I look after Jenkins > > issues at least once a day. Here's yesterday: > > (1) manually triggered a number of PIM builds that were stuck due to having > > ran in the wrong order, I'm sure the Jenkins log will confirm that if you > > don't believe me. > > Now here's my question to sysadmins: > > Failures caused by the testing system being unable to build things in order > has *always* being present and doesn't only concerns the pim repositories. > > What did you do to fix the repeated failures caused by systems you maintain? > There is nothing that can be done to delay builds for one repository on the build of another at this present time. Neither Jenkins or Gitlab CI provide the necessary support for us to link jobs together in the way that PIM demands in this case here. For Jenkins, it's support for this is done through "upstream/downstream jobs". When specified in a job configuration, these result in downstream jobs being triggered when upstream jobs built. If the full dependency chain were to be set in Jenkins this would have the highly undesirable side effect of rebuilding everything in KDE each time a commit were made to one or more of the Frameworks repositories. As i'm sure you can understand, that is not sustainable or scalable in any form. I should also note that this functionality does not always behave in the manner you would expect (see https://issues.jenkins-ci.org/browse/JENKINS-22800) and therefore cannot be relied on to do this in any case. In terms of Gitlab, while it does allow triggering jobs in other projects as part of a job run (see https://docs.gitlab.com/ee/ci/multi_project_pipelines.html) this is limited to a dependency chain only. It does not extend to waiting for the parent job to complete. Therefore at this time what you are requesting is not technically possible with either the solution we are currently on, or the solution we are looking at moving to. The generally accepted solution to this class of issue is to: 1) Ensure things such as version bumps are done in two phases, with the version bump and dependency bump happening in separate commit/push rounds 2) Perform pushes to repositories in the correct order, and provide some time between them rather than doing them immediately. (1) is how Frameworks manages this problem in particular. I know in the past that PIM has not followed, and has refused to follow when suggested, this practice. Regards, Ben
Re: The KDEPIM / Akonadi situation
On Friday, 12 June 2020 23:54:19 CEST Ben Cooksley wrote: > On Sat, Jun 13, 2020 at 7:49 AM Andras Mantia wrote: > > Hey, > > Hi all, > > > don't want to add much as I'm not active anymore and have my share of > > fault > > > for not fixing certain bugs, but I'd like to reply to only one thing... > > > > On Friday, June 12, 2020 6:11:31 AM EEST Nate Graham wrote: > > > However I think there is a bigger challenge that just the technical > > > issues. My interactions in bug reports have been quite negative, I have > > > to say, and I don't feel like the developer culture is very welcoming > > > right now. > > > > Sorry if you had bad experience, not sure what happened, but I can assure > > that > > > most (or rather: all) developers I worked with in the PIM area were nice > > and > > > friendly. > > They are however, terrible at reading emails from the CI system. To the > point I suspect they have filters sending such mail to the trash so it is > never seen. sigh, not this again please... Ben, you very well know I look after Jenkins issues at least once a day. Here's yesterday: (1) manually triggered a number of PIM builds that were stuck due to having ran in the wrong order, I'm sure the Jenkins log will confirm that if you don't believe me. (2) submitted a first step towards fixing the Android failures caused by the anongit shutdown, https://invent.kde.org/sysadmin/ci-tooling/-/merge_requests/ 78, you should know having merged that yourself even. (3) submitted the first batch of fixes for the broken Flatpak builds due to the anongit shutdown, https://invent.kde.org/packaging/flatpak-kde-runtime/-/ merge_requests/13 (still needs review) The Akonadi/FreeBSD issue persists since more than 48h, so why didn't I look into that the day before yesterday then? Because I was fixing the Yocto builds due to the anongit shutdown: - https://invent.kde.org/packaging/yocto-meta-kf5/-/commit/ e5e32bcb41aa3922b0885de0ac3355a36bffad80 - https://invent.kde.org/packaging/yocto-meta-kde/-/commit/ e6925a5737ab8ec2fe9dd0281b58579c3fbb74fb > Akonadi has been in a broken state for several days now on FreeBSD. They > have received multiple notices of this to their mailing list, and yet no > action has been taken. > > Because other software outside of PIM depends on Akonadi, the dependency > builds for the CI system are unable to successfully finish (failing in > Akonadi), meaning the CI system is now effectively unmaintainable on > FreeBSD. I am very well aware of the ripple effects such failures can have, see the above work on dealing with the anongit shutdown fallout. > Continued builds for software in Extragear and Release Service are > therefore currently dependent on the Binary Compatibility of the system not > being broken. > > Should anything happen to affect that then all of those builds will cease > to work and be unfixable. That is a situation that I find fundamentally > unacceptable. > > This type of issue has come up numerous times before, and is one that the > PIM developers have failed to address. > > I'm therefore at a loss for options going forward and think that the only > reasonable and viable solution in the long run will be to blacklist Akonadi > from the CI system, and remove CI builds for everything with a hard > dependency on it, including all of KDE PIM. I have finite time and prioritized what seemed to have most wide-spread impact (all of Android and all of Flatpak vs. Akonadi/FreeBSD), as well as things that are most efficient for me to fix (Yocto vs. FreeBSD, having the necessary setup locally). If there are considerations I'm missing here you could just have talked to me directly, no need to resort to threats. Regards, Volker
Re: The KDEPIM / Akonadi situation
El divendres, 12 de juny de 2020, a les 23:54:19 CEST, Ben Cooksley va escriure: > On Sat, Jun 13, 2020 at 7:49 AM Andras Mantia wrote: > > > > Hey, > > Hi all, > > > > > don't want to add much as I'm not active anymore and have my share of > fault > > for not fixing certain bugs, but I'd like to reply to only one thing... > > > > On Friday, June 12, 2020 6:11:31 AM EEST Nate Graham wrote: > > > However I think there is a bigger challenge that just the technical > > > issues. My interactions in bug reports have been quite negative, I have > > > to say, and I don't feel like the developer culture is very welcoming > > > right now. > > > > Sorry if you had bad experience, not sure what happened, but I can assure > that > > most (or rather: all) developers I worked with in the PIM area were nice > and > > friendly. > > They are however, terrible at reading emails from the CI system. To the > point I suspect they have filters sending such mail to the trash so it is > never seen. > > Akonadi has been in a broken state for several days now on FreeBSD. They > have received multiple notices of this to their mailing list, and yet no > action has been taken. > > Because other software outside of PIM depends on Akonadi, the dependency > builds for the CI system are unable to successfully finish (failing in > Akonadi), meaning the CI system is now effectively unmaintainable on > FreeBSD. > > Continued builds for software in Extragear and Release Service are > therefore currently dependent on the Binary Compatibility of the system not > being broken. > > Should anything happen to affect that then all of those builds will cease > to work and be unfixable. That is a situation that I find fundamentally > unacceptable. > > This type of issue has come up numerous times before, and is one that the > PIM developers have failed to address. > > I'm therefore at a loss for options going forward and think that the only > reasonable and viable solution in the long run will be to blacklist Akonadi > from the CI system, and remove CI builds for everything with a hard > dependency on it, including all of KDE PIM. On the other hand maybe we just need to accept that we don't have enough people that care about FreeBSD and just remove the akonadi+dependants-FreeBSD builds and not the all the Akonadi+dependants builds. Cheers, Albert > > > > > Andras > > > > > > Regards, > Ben >
Re: The KDEPIM / Akonadi situation
On Sat, Jun 13, 2020 at 7:49 AM Andras Mantia wrote: > > Hey, Hi all, > > don't want to add much as I'm not active anymore and have my share of fault > for not fixing certain bugs, but I'd like to reply to only one thing... > > On Friday, June 12, 2020 6:11:31 AM EEST Nate Graham wrote: > > However I think there is a bigger challenge that just the technical > > issues. My interactions in bug reports have been quite negative, I have > > to say, and I don't feel like the developer culture is very welcoming > > right now. > > Sorry if you had bad experience, not sure what happened, but I can assure that > most (or rather: all) developers I worked with in the PIM area were nice and > friendly. They are however, terrible at reading emails from the CI system. To the point I suspect they have filters sending such mail to the trash so it is never seen. Akonadi has been in a broken state for several days now on FreeBSD. They have received multiple notices of this to their mailing list, and yet no action has been taken. Because other software outside of PIM depends on Akonadi, the dependency builds for the CI system are unable to successfully finish (failing in Akonadi), meaning the CI system is now effectively unmaintainable on FreeBSD. Continued builds for software in Extragear and Release Service are therefore currently dependent on the Binary Compatibility of the system not being broken. Should anything happen to affect that then all of those builds will cease to work and be unfixable. That is a situation that I find fundamentally unacceptable. This type of issue has come up numerous times before, and is one that the PIM developers have failed to address. I'm therefore at a loss for options going forward and think that the only reasonable and viable solution in the long run will be to blacklist Akonadi from the CI system, and remove CI builds for everything with a hard dependency on it, including all of KDE PIM. > > Andras > > Regards, Ben
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
Now actually really cc'ing KDEPIM development mailing list. In order to do so I waited more than a minute for KMail receiving a response with the payload of the mail I just sent as Akonadi maildir resource was using 100% of one core while synchronizing the sent folder with about 34000 mails. Then I lost the patience, did "killall akonadi_maildir_resource" to make KMail respond immediately again. 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
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
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
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
On Fri, Jun 12, 2020 at 6:04 AM Friedrich W. H. Kossebau wrote: > Am Freitag, 12. Juni 2020, 05:11:31 CEST schrieb Nate Graham: > > However I think there is a bigger challenge that just the technical > > issues. My interactions in bug reports have been quite negative, I have > > to say, and I don't feel like the developer culture is very welcoming > > right now. > I'm reading in here late, sorry. It takes two to tango. I have not had negative experience with KDE PIM > people. > > And Nate, if I saw you advocating to have my KDE software removed from KDE- > centric distributions (even more when triggered because some proprietary- > privacy-screwing service support being broken, is that what KDE is about?) > like in https://phabricator.kde.org/T12486 , that would magically lower > the > quality of my interaction in bug reports with you as well. And no, this is > not > about who started. > Nate was acting there on behalf of Kubuntu, since we were putting out an LTS last time. We get so many user issues with PIM, especially with the Gmail situation. Nobody blamed the KDE PIM devels, but as a distro, Kubuntu has to act to offer our users the most friendly, welcoming environment. We can't ship software that won't work for a large swath of users. KDE PIM is packaged and available as always. Sadly, we had to drop Amarok until it returns to the new Kf5 world. It is our policy to offer all the quality KDE software with the fewest patches possible, and Nate has been a huge help in that effort. 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 > about our very important issues and our oh so very clever and well done > solution/fixes/improvements, with all their politeness, spending all of > their > time just for us, or where we see them going wrong ways and how they fail > to > meet other products quality and features. > He, one could use Gnome, Visual Studio Code, Thunderbird. etc. pp., who > needs > KDE!!1! > > I am missing what this email thread here should achieve, despite being > demotivating for those whose product is talked about or even bad-mouthing > them. We all know there are big and small flaws. Those get fixed by people > working on them. Not by people showing off their knowledge that there are > flaws. And I doubt the developers of the products do not know about the > flaws. > They just do not have the resources left to handle them, given resources > are > limited. > > And when you compare KDEPIM to Evolution and Thunderbird, you also want to > compare the current resources behind. Which of those products has > developers > behind that work on them during paid jobs, not only in their leisure time? > > I am happy to be able to use KMail, all the years. > Unfortunately I have not, and it used to be my favorite application. But what to put on the ISO is not personal favorite or not, but about what is the best experience for users. If you want to help KDEPIM, but cannot become the needed qualified > developer > to help by being another resource yourself, see to make business plans > instead > to organize the needed resources to get more funded developers. If you > also > cannot do that, bad luck. World will not be improved by you. > PIM is more complex given all the various data and service specifications > and > various buggy implementations of them which have to be handled to please > user > expectations. And you have to be able to also manage massive amounts of > data > without annoying the user by waiting times. It's not what your beginner/ > amateur developer can easily do. KDEPIM thankfully still has some > professional > developers around who invest their leisure time now and then. I am > thankful > they do, so KDEPIM is not dead. From my few bug reports in the last > months, > some of them were fixed the other day or were already before. > > Cheers > Friedrich > -- http://about.me/valoriez - pronouns: she/her
Re: The KDEPIM / Akonadi situation
Hey, don't want to add much as I'm not active anymore and have my share of fault for not fixing certain bugs, but I'd like to reply to only one thing... On Friday, June 12, 2020 6:11:31 AM EEST Nate Graham wrote: > However I think there is a bigger challenge that just the technical > issues. My interactions in bug reports have been quite negative, I have > to say, and I don't feel like the developer culture is very welcoming > right now. Sorry if you had bad experience, not sure what happened, but I can assure that most (or rather: all) developers I worked with in the PIM area were nice and friendly. Andras
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
Le vendredi, juin 12, 2020 1:45 PM, Kevin Ottens a écrit : > On Friday, 12 June 2020 15:17:46 CEST Christian Loosli wrote: > > > Am Freitag, 12. Juni 2020, 15:04:34 CEST schrieb Friedrich W. H. Kossebau: > > > > > I am missing what this email thread here should achieve, despite being > > > demotivating for those whose product is talked about or even bad-mouthing > > > them. We all know there are big and small flaws. Those get fixed by people > > > working on them. Not by people showing off their knowledge that there are > > > flaws. And I doubt the developers of the products do not know about the > > > flaws. They just do not have the resources left to handle them, given > > > resources are limited. > > > > My personal hope would be that some solutions could be discussed, e.g. on > > how to get more developers, if some parts should be dropped / rewritten > > instead of fixed etc. > > Incidentally it's been the top discussion topics for the past few KDEPIM > sprints. And also during BoFs at Akademy. I even think there's been > discussions about that on the pim list and IRC channels. And I think the PIM team did a lot of good work in this direction, there is documentation on how to build the PIM libs and apps, a big list of junior jobs with that in my experience get active mentoring when someone wants to claim one of them. Could the PIM team make the whole onboarding process easier? Probably but it would also impact the limited time the PIM devs have to work on the PIM apps. But in my opinion that makes it very hard to get more devs working on the PIM apps is that this is a complex system and that it is not the cool new tech but instead, deals with tons of legacy systems. If someone wants to help the PIM team, I would recommend taking one of the junior jobs or updating the documentation related to PIM on the wikis. If I remember correctly I got my KDE developer account with the support of Laurent after completing one of the Junior Job, so merci beaucoup Laurent and the rest of the team for making me discover the KDE community. Cheers, Carl > > Regards. > > -- > > Kevin Ottens, http://ervin.ipsquad.net publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
Am Freitag, 12. Juni 2020, 15:45:29 CEST schrieb Kevin Ottens: Hello Kevin, > Incidentally it's been the top discussion topics for the past few KDEPIM > sprints. And also during BoFs at Akademy. I even think there's been > discussions about that on the pim list and IRC channels. that is great to hear! Sounds like it is a rather long-term / time consuming process, therefore: do you think there could be something KDE could do to help? As in: would more attention (which a goal would likely achieve) help? Would (sponsored) sprints help? Developers? Money? Or do we just need to be more patient? I'm just afraid that we might indeed lose people or whole distributions to other products if the frustration level is too high, I know mine occasionally is and I do try out other products, too. > Regards. Kind regards, Christian
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
On Friday, 12 June 2020 15:17:46 CEST Christian Loosli wrote: > Am Freitag, 12. Juni 2020, 15:04:34 CEST schrieb Friedrich W. H. Kossebau: > > I am missing what this email thread here should achieve, despite being > > demotivating for those whose product is talked about or even bad-mouthing > > them. We all know there are big and small flaws. Those get fixed by people > > working on them. Not by people showing off their knowledge that there are > > flaws. And I doubt the developers of the products do not know about the > > flaws. They just do not have the resources left to handle them, given > > resources are limited. > > My personal hope would be that some solutions could be discussed, e.g. on > how to get more developers, if some parts should be dropped / rewritten > instead of fixed etc. Incidentally it's been the top discussion topics for the past few KDEPIM sprints. And also during BoFs at Akademy. I even think there's been discussions about that on the pim list and IRC channels. Regards. -- Kevin Ottens, http://ervin.ipsquad.net signature.asc Description: This is a digitally signed message part.
Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)
Am Freitag, 12. Juni 2020, 15:04:34 CEST schrieb Friedrich W. H. Kossebau: > I am missing what this email thread here should achieve, despite being > demotivating for those whose product is talked about or even bad-mouthing > them. We all know there are big and small flaws. Those get fixed by people > working on them. Not by people showing off their knowledge that there are > flaws. And I doubt the developers of the products do not know about the > flaws. They just do not have the resources left to handle them, given > resources are limited. My personal hope would be that some solutions could be discussed, e.g. on how to get more developers, if some parts should be dropped / rewritten instead of fixed etc. I definitely don't say that other KDE apps or Plasma do not have issues, but in my personal, daily workflow, PIM is the place where I get stuck more often than not. Most recent example is the one I mentioned in my initial reply, that kmail would not let me reply to an e-mail for a minute with a semi-helpful popup message with an cycling-progressbar. Personally I'd prefer the discussions being non-ranty and non heated, but removal of KDEPim was not discussed in the Phab task you linked for the first time, I remember a rather lenghty rant from a Gentoo packager, too. (Who was proposing to ship pre-akonadi KDE PIM as long as possible). These rants are obviously hurtful to people working on the software, but I also think they might show a bigger frustration that needs to be addressed. So I think if we can shift focus a bit on pieces of a "KDE distribution" that are vital for work (and I consider PIM very vital) that need more (urgent) attention than others, then that would be great. That's why we have specified goals, it is to focus. And focus does not mean laying blame on people, I'm sure the KDE PIM developers do their very best with the limited ressources and the complexity they have to tackle. It means trying to help. > Cheers > Friedrich Kind regards, Christian
Showing respect (was: Re: The KDEPIM / Akonadi situation)
Am Freitag, 12. Juni 2020, 05:11:31 CEST schrieb Nate Graham: > However I think there is a bigger challenge that just the technical > issues. My interactions in bug reports have been quite negative, I have > to say, and I don't feel like the developer culture is very welcoming > right now. It takes two to tango. I have not had negative experience with KDE PIM people. And Nate, if I saw you advocating to have my KDE software removed from KDE- centric distributions (even more when triggered because some proprietary- privacy-screwing service support being broken, is that what KDE is about?) like in https://phabricator.kde.org/T12486 , that would magically lower the quality of my interaction in bug reports with you as well. And no, this is not about who started. 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 about our very important issues and our oh so very clever and well done solution/fixes/improvements, with all their politeness, spending all of their time just for us, or where we see them going wrong ways and how they fail to meet other products quality and features. He, one could use Gnome, Visual Studio Code, Thunderbird. etc. pp., who needs KDE!!1! I am missing what this email thread here should achieve, despite being demotivating for those whose product is talked about or even bad-mouthing them. We all know there are big and small flaws. Those get fixed by people working on them. Not by people showing off their knowledge that there are flaws. And I doubt the developers of the products do not know about the flaws. They just do not have the resources left to handle them, given resources are limited. And when you compare KDEPIM to Evolution and Thunderbird, you also want to compare the current resources behind. Which of those products has developers behind that work on them during paid jobs, not only in their leisure time? I am happy to be able to use KMail, all the years. If you want to help KDEPIM, but cannot become the needed qualified developer to help by being another resource yourself, see to make business plans instead to organize the needed resources to get more funded developers. If you also cannot do that, bad luck. World will not be improved by you. PIM is more complex given all the various data and service specifications and various buggy implementations of them which have to be handled to please user expectations. And you have to be able to also manage massive amounts of data without annoying the user by waiting times. It's not what your beginner/ amateur developer can easily do. KDEPIM thankfully still has some professional developers around who invest their leisure time now and then. I am thankful they do, so KDEPIM is not dead. From my few bug reports in the last months, some of them were fixed the other day or were already before. Cheers Friedrich
Re: The KDEPIM / Akonadi situation
Nate Graham - 12.06.20, 05:11:31 CEST: > software. I'm currently using Thunderbird as my email client and it is > boringly reliable. Everything works 100%, 100% of the time. There is > no drama whatsoever, and no maintenance required. That's the goal Seriously +1 on that. This exactly matches my experience with Evolution and Evolution EWS for accessing work mail (stored on Office 365). I switched to Evolution there cause with Akonadi EWS sending mails often failed. No crash, no maintenance, no drama, no nothing. This thing *just works*. And I'd say the scope of Evolution has similar complexity than the scope of KDEPIM. At least the feature sets are somewhat similar. I bet KDEPIM and Akonadi may be a bit more flexible and have a feature more here and there, but IMAP, POP3, locally stored mail, EWS, calender, address book, GPG support and a lot of other features are all there. And again: This is no offense meant. I am grateful for all the work KDEPIM developers did. All the free time they volunteered! I expressed that gratitude several times and I am happy to express it again. I helped with bug triage, user support, I defended Akonadi, tried to help to bring people together. With considerable help of KDE developers I helped to fix a serious past performance issue with maildir resource (needless sorting of filenames during folder sync)… However being grateful does not somehow disallow to raise an issue that exists since a long time. The issue, that Akonadi based KDEPIM fails to provide the reliability and speed that users expect to experience when they use a PIM application suite. "akonadictl fsck", "item without RID", database administration, duplicated mail, stuck Akonadi resources, waiting for one or several minutes before being able to reply to a mail in KMail and things like that – no user should ever have to deal with *any of that* just so use PIM applications, no matter how good they otherwise are. Being grateful does not somehow exclude raising the issue that all of this is still there with KDEPIM and Akonadi 20.04. And that all of this has been here for years. Quite the contrary. I think it is a disservice to the KDEPIM project to pretend that this is not there. At least I can imagine that developers like to have happy users. I see people invested a lot of time. And I am truly grateful for that. It is just that the investment of time did somehow not lead to a result where the stability, reliability and speed of KDEPIM matches that of Evolution or Thunderbird. And by stating that I do not mean to diminish the progress KDEPIM developers achieved in any way. I do think it is important to see this. And accept it. And then it can be possible to move beyond… Not seeing it seems to keep KDEPIM stuck where it currently is, *despite* all the effort. Best, -- Martin
Re: The KDEPIM / Akonadi situation
It's quite possible to take a large and technically flawed project and fix the technical flaws over time. Arguably this has happened in Baloo over the past year or two, and I see far fewer user complaints about it than I did in the past. It's working almost perfectly for me. I don't know enough about Akonadi's technical undrpinnings to say whether this will be possible there, or whether it's just an impossible undertaking though. However I think there is a bigger challenge that just the technical issues. My interactions in bug reports have been quite negative, I have to say, and I don't feel like the developer culture is very welcoming right now. This probably has to change or else the project will fail to attract the kind of manpower needed to achieve a state of greater reliability, which I think needs to be the top priority in business-ish software. I'm currently using Thunderbird as my email client and it is boringly reliable. Everything works 100%, 100% of the time. There is no drama whatsoever, and no maintenance required. That's the goal. Nate
Re: The KDEPIM / Akonadi situation
Hi Martin, thank you very much for bringing this up. I had a minor rant about the situation on the enterprise list back when I also used KDE apps at work, I'm afraid from what I can see the situation is mostly the same. I ended up with a messed up DB a couple of times that I was only able to solve by simply deleting and re-adding the IMAP account. As a funny bit of irony, I tried to reply to your message earlier, but kmail wouldn't let me because it asked me, with a pop up, to wait for transmission of the message for a couple of minutes. Unfortunately I also don't have any ready-made solution for it, we can't really force people to work on a certain product, and the whole akonadi-stack is probably also not something terribly new-person-friendly. I know that there was an alternative being worked on, but I lost track of that as well. Maybe making it a goal could help, or to have some sort of sprint around it. Or, even though I personally am usually very much against these, some sort of bounty. In any case I think the situation needs improvement and I'm glad you brought it up, so this is mostly in support of the request, because it stayed reply- less for a while. Kind regards, Christian
The KDEPIM / Akonadi situation
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
