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

[Valorie Zimmerman]

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.

I love you all.

Valorie

On Tue, Oct 15, 2019 at 1:04 AM Volker Krause <vkrause at kde.org> wrote:

> 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
>


-- 
http://about.me/valoriez - pronouns: she/her
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20191016/18374546/attachment-0001.html>