Reverting R490:abfdd65f0c85: Use URLs in multiget requests as returned by the Server for Kolab users

[Volker Krause]

On Tuesday, 15 October 2019 03:46:18 CEST Valorie Zimmerman wrote:
> Thanks much for your speedy answers!
> 
> On Mon, Oct 14, 2019 at 2:02 AM Volker Krause <vkrause at kde.org> wrote:
> > Hi Valorie,
> > 
> > On Monday, 14 October 2019 04:28:59 CEST Valorie Zimmerman wrote:
> > > Hello PIMsters,
> > > 
> > > We (the CWG ) have gotten a very well-reasoned and outraged email from a
> > > passionate KDE and PIM user, who can no longer use their calendar
> > > because
> > > of:
> > > 
> > > [1] https://bugs.kde.org/show_bug.cgi?id=386985
> > > [2] https://phabricator.kde.org/D8843
> > > 
> > > Can you please either add back the reverted patch that fixed the problem
> > > for a multitude of users, or help Kolab fix their issue, or ?
> > > 
> > > It really is not OK to favor users of a particular Kolab server over
> > > many
> > > other users who do not use this server.
> > > 
> > > If there is more behind this, please explain it so we can clarify this
> > > to
> > > our users.
> > 
> > it is of course understandably frustrating when hit by this issue and thus
> > having no access to ones calendar, I think everyone agrees that this
> > should be
> > fixed.
> > 
> > However, before jumping to conclusions, let's review what happened
> > (looking at
> > D8443):
> > - D8443 is proposed, reviewed and integrated in November 2017.
> > - Within a week a regression is discovered, namely it breaking access to
> > some
> > Kolab servers (because the people running master happen to use that, if
> > that's
> > actually the only affected server is actually unknown I think).
> > - Given the short timeframe to the 17.12 release and a lack of a fix or
> > even a
> > full analysis of the problem and its impact, the patch get reverted.
> > - Nothing happens for about a year
> > - In Nov 2018 discussion restarts about how to find out what is actually
> > wrong
> > here.
> > - Discussion stalls in Feb 27 with David providing a diagnostic patch,
> > asking
> > someone affected to apply that and provide the resulting output, which
> > never
> > happened.
> 
> If I can speak for the outraged user, it is the delay along with the
> perceived reasoning for the quick reversion of a patch that briefly made
> their calendar(s) *work*.

I understand the frustration if a seemingly working patch is rolled back. That 
however is the standard procedure (not just in KDE) if a severe regression is 
discovered and if no quick fix can be found, even more so if the full impact 
isn't understood yet and/or shortly before a release.

That the problem still hasn't been fixed two years later is most unfortunate 
of course.

> > It is also worth noting that this isn't a "a particular Kolab server" vs.
> > "many other users", far from it. The current code works perfectly fine
> > with
> > many other servers out there, such as Nextcloud. In fact nobody I'm aware
> > of
> > in the PIM team even has access to an affected server, which is what makes
> > it
> > difficult to work on a patch.
> 
> Right.
> 
> D8443 ended with a patch to test for anyone who has access to an affected
> 
> > server so we can progress that. Not doing that and instead asking for a
> > patch
> > to be applied that breaks things for other users doesn't seem like an
> > appropriate way forward to me.
> > 
> > Regards,
> > Volker
> 
> If I might point out that not all users know how to apply a patch to test
> it, or to fork the code so that they have a working copy. If we want *lots
> more users* of our code, we have to keep that in mind.

I am sure David did not expect the average user to apply that patch there, but 
was aiming at the people that clearly have a working development setup and 
access to an affected server, such as the author of the patch in question or 
the people that obviously managed to test that patch.

I'd also like to challenge the either/or question that often seems to be 
assumed in this context. As mentioned in another reply yesterday, DavDroid 
seems to be able to talk to all servers just fine, and their multi-get command 
looks very much like our current implementation if I'm not mistaken. That 
would suggest to me that there is a proper solution to this that makes 
everyone happy, rather than trading one user's use-case for that of another 
one.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20191015/79fd2e60/attachment.sig>