https://bugs.kde.org/show_bug.cgi?id=481024
--- Comment #39 from Flossy Cat <flossy-...@online.de> --- (In reply to Martin Steigerwald from comment #33) > I understand your frustrations, Flossy Cat. I truly do. KDEPIM has been a > big trigger of frustrations for me as well. Thanks for your quantum of solace, but this is not about "frustrations" – please see comment 36, my answer to Bernhard. > … > But I do also appreciate that the KDEPIM development team is very small. And > they care about their software. That can be seen again and again like for > example in the blog posts about the recent meetup they had. When I opened this bug the crippling change (silent scraping of korgac) was already 2 years old. (see comment 8 and the related bugs) Very obviously nobody considered the usability impact of this: Even the most simplistic users of any calendaring tool I can question, immediately answer that only being able to snooze reminders for 5 min or 1 h would not be acceptable … The first bug reports complaining about the effects of this change happened 6 month after the change and 18 month before my bug report. To no avail … – they were ignored … I can't rely upon software with this level of care – and I don't care for software which is cared for like this. > Also I see that the change implemented by David has more than 160 new lines > and changes more than 30 other lines. That IMHO is quite a bit for a > backport. David extracted code from the scrapped "korgac" and re-implanted it. This is neither a "new feature" nor "160 new lines" if "new" is used with its usual meaning of "something not present earlier". The change to fix the regression might change around 200 lines to arrive from "crippled" to "usable" again, but many of these (as well as the functionality) have been present for many many years. > But… another approach would be, to talk with openSUSE people > whether a backport can be done and maybe try to bring forth a back port in > cooperation between upstream and distro developers? From what I read > openSUSE volunteer based team is also quite small Exactly. The small KDEPIM team causes a use-breaking regression by some ill-considered decision. It then ignores all early warnings about the problem and freezes the LTS versions so that when these decisions start to hurt users relying on KDEPIM no easy backport of the fix and no easy propagation to the suffering users is feasible. Instead I should involve the (equally) understaffed openSUSE team (and other users their respective distro teams). This multiplies the effort needed in comparison with the KDEPIM team just realizing how ill-considered their decision was and fixing it. If FOSS teams are understaffed (and they definitely are!) this is a very stupid strategy. Or we go with David's idea of each user compiling for themselves, further multiplying the effort (and dangerous, as the self-compiled version does not receive automatic security patches). I go with my idea: switch to a PIM solution actually caring for end user experience … > and I am not sure whether KDEPIM is a focus for the enterprise variants of > SUSE, It isn't. The default choice there is Evolution. I always wondered why, because I regularly every few years reevaluate my SW choices, and Kontact so far always had a slight edge on Evolution and Thunderbird (but the gap was closing). With this regression Kontact is far behind and the whole handling of this regression deeply undermines my trust in KDEPIM. If the SLE team had similar experience I now understand the preference for Evolution. > an approach where you could use your energy in a constructive manner to > resolve the issue at hand for you and others. Especially also if that fix is > required by enterprises that use KDEPIM… It would be … > have you consider to ask for or > organize some paid development work on making a back port? Remember a lot of > work on KDEPIM is volunteer work. That means it is often enough work done by > people who also have to do something else to earn money. I'm a seasoned computer engineer supporting FOSS since 1986, mostly by contributed code and bug fixes and I offered my active support with this bug report – to no avail. -- You are receiving this mail because: You are watching all bug changes.
