KDav without KIO

laurent Montel montel at kde.org
Mon Jun 26 20:45:20 BST 2017


Le lundi 26 juin 2017, 12:25:14 CEST Christian Mollekopf a écrit :
> On Mon, Jun 26, 2017, at 11:45 AM, laurent Montel wrote:
> > Le lundi 26 juin 2017, 11:08:1 CSTLuca Beltrame a écrit :
> > > Il giorno Mon, 26 Jun 2017 10:45:26 +0200
> > >
> > >Christian Mollekopf <chrigi_1 at fastmail.fm> ha scritto:
> > > > I'm not even building kdepim, so I can't offer that, sorry. Perhaps
> > > > Sandro can given he's the one that ported the resource to kdav.
> > > 
> > > As a downstream packager, I'd give a -1 to merging this (FWIW) unless
> > > it has been at least superficially tested with the current PIM (not that
> > > *you* have to do so, but as long as *someone* does that).
> > > 
> > > The DAV resource is exceptionally quirky by itself (according to my
> > > unspecific experience in the KDE Community Forums), so better to not add
> > > additional (potential) regressions.
> > 
> > Indeed we need be sure that there is not regressions.
> 
> I agree with you and Luca, if you want to use this in kdepim, then
> somebody will have to test it and fix problems if there are any.
> I'm happy to work on specific defects in the kdav code, but I'm not
> going to make sure the dav resource has no regressions.

As you can see it's a problem as we are not a big team, and main dev of dav 
resource is not active.

> 

> I think there are a few ways forward:
> * Somebody steps up and does the necessary DAV Resource work so we can
> move forward.
> * You agree that this is generally the right direction and overall a
> better solution (I know I do), but you can't do the work right now.
> Given this is an intrusive change (although currently without API
> changes), we could argue we just bump to KDav2 (notwithstanding that we
> have a completely different version number in the CMakeFile...), so you
> can stick to what you use now and move at your own pace. This would be
> pretty much the same as KIMAP2.
> * You disagree with the direction and I'll have to figure out a sensible
> name for my new library.
> 
> I hope we can do either solution 1 or 2, because those seem the most
> sensible to me.
> Anyways, I hope this perhaps explains my situation better =)

I understand your situation, but if we look at kdepim perspective your patch 
will be not an improvement, you just remove kio support, without adding more 
autotests or make sure that dav resources still work without regressions.

Actually we have a resource which works, we don't have a maintainer, so if we 
accept your patch without warranty that there is not regressions it will be a 
big problem for us, and it will give us more works...

So creating a repo kdav2 seems to be a good idea, so a day when a maintainer 
will decide to evaluate kdav2 + kdepim we will be able to port it.

But actually I think it's not safe to accept your patch.

Perhaps in the future if there is more autotests, more testcases etc we can 
re-evaluate the situation.

But I am not sure that Dan or me we want to debug future problem in kdav 
resource.


Regards.


> 
> Cheers,
> Christian


-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 
 www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent 
software solutions 



More information about the kde-pim mailing list