[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

[Flossy Cat]

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #39 from Flossy Cat <flossy-cat at 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 the assignee for the bug.