<div dir="ltr"><div>Thanks so much for dealing with the issue, rather than reacting with defensiveness. It's really lovely to be able to help an outraged user find a solution within one of our amazing teams. </div><div><br></div><div>I love you all.</div><div><br></div><div>Valorie</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 15, 2019 at 1:04 AM Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, 15 October 2019 03:46:18 CEST Valorie Zimmerman wrote:<br>
> Thanks much for your speedy answers!<br>
> <br>
> On Mon, Oct 14, 2019 at 2:02 AM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > Hi Valorie,<br>
> > <br>
> > On Monday, 14 October 2019 04:28:59 CEST Valorie Zimmerman wrote:<br>
> > > Hello PIMsters,<br>
> > > <br>
> > > We (the CWG ) have gotten a very well-reasoned and outraged email from a<br>
> > > passionate KDE and PIM user, who can no longer use their calendar<br>
> > > because<br>
> > > of:<br>
> > > <br>
> > > [1] <a href="https://bugs.kde.org/show_bug.cgi?id=386985" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=386985</a><br>
> > > [2] <a href="https://phabricator.kde.org/D8843" rel="noreferrer" target="_blank">https://phabricator.kde.org/D8843</a><br>
> > > <br>
> > > Can you please either add back the reverted patch that fixed the problem<br>
> > > for a multitude of users, or help Kolab fix their issue, or ?<br>
> > > <br>
> > > It really is not OK to favor users of a particular Kolab server over<br>
> > > many<br>
> > > other users who do not use this server.<br>
> > > <br>
> > > If there is more behind this, please explain it so we can clarify this<br>
> > > to<br>
> > > our users.<br>
> > <br>
> > it is of course understandably frustrating when hit by this issue and thus<br>
> > having no access to ones calendar, I think everyone agrees that this<br>
> > should be<br>
> > fixed.<br>
> > <br>
> > However, before jumping to conclusions, let's review what happened<br>
> > (looking at<br>
> > D8443):<br>
> > - D8443 is proposed, reviewed and integrated in November 2017.<br>
> > - Within a week a regression is discovered, namely it breaking access to<br>
> > some<br>
> > Kolab servers (because the people running master happen to use that, if<br>
> > that's<br>
> > actually the only affected server is actually unknown I think).<br>
> > - Given the short timeframe to the 17.12 release and a lack of a fix or<br>
> > even a<br>
> > full analysis of the problem and its impact, the patch get reverted.<br>
> > - Nothing happens for about a year<br>
> > - In Nov 2018 discussion restarts about how to find out what is actually<br>
> > wrong<br>
> > here.<br>
> > - Discussion stalls in Feb 27 with David providing a diagnostic patch,<br>
> > asking<br>
> > someone affected to apply that and provide the resulting output, which<br>
> > never<br>
> > happened.<br>
> <br>
> If I can speak for the outraged user, it is the delay along with the<br>
> perceived reasoning for the quick reversion of a patch that briefly made<br>
> their calendar(s) *work*.<br>
<br>
I understand the frustration if a seemingly working patch is rolled back. That <br>
however is the standard procedure (not just in KDE) if a severe regression is <br>
discovered and if no quick fix can be found, even more so if the full impact <br>
isn't understood yet and/or shortly before a release.<br>
<br>
That the problem still hasn't been fixed two years later is most unfortunate <br>
of course.<br>
<br>
> > It is also worth noting that this isn't a "a particular Kolab server" vs.<br>
> > "many other users", far from it. The current code works perfectly fine<br>
> > with<br>
> > many other servers out there, such as Nextcloud. In fact nobody I'm aware<br>
> > of<br>
> > in the PIM team even has access to an affected server, which is what makes<br>
> > it<br>
> > difficult to work on a patch.<br>
> <br>
> Right.<br>
> <br>
> D8443 ended with a patch to test for anyone who has access to an affected<br>
> <br>
> > server so we can progress that. Not doing that and instead asking for a<br>
> > patch<br>
> > to be applied that breaks things for other users doesn't seem like an<br>
> > appropriate way forward to me.<br>
> > <br>
> > Regards,<br>
> > Volker<br>
> <br>
> If I might point out that not all users know how to apply a patch to test<br>
> it, or to fork the code so that they have a working copy. If we want *lots<br>
> more users* of our code, we have to keep that in mind.<br>
<br>
I am sure David did not expect the average user to apply that patch there, but <br>
was aiming at the people that clearly have a working development setup and <br>
access to an affected server, such as the author of the patch in question or <br>
the people that obviously managed to test that patch.<br>
<br>
I'd also like to challenge the either/or question that often seems to be <br>
assumed in this context. As mentioned in another reply yesterday, DavDroid <br>
seems to be able to talk to all servers just fine, and their multi-get command <br>
looks very much like our current implementation if I'm not mistaken. That <br>
would suggest to me that there is a proper solution to this that makes <br>
everyone happy, rather than trading one user's use-case for that of another <br>
one.<br>
<br>
Regards,<br>
Volker<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><a href="http://about.me/valoriez" target="_blank">http://about.me/valoriez</a> - pronouns: she/her<br><br><br></div></div></div></div>