[Kde-graphics-devel] Fwd: libkface

[Gilles Caulier]

---------- Forwarded message ----------
From: Gilles Caulier <caulier.gilles at gmail.com>
Date: 2014-09-18 22:51 GMT+02:00
Subject: Re: [Kde-graphics-devel] libkface
To: Albert Astals Cid <aacid at kde.org>


2014-09-18 22:38 GMT+02:00 Albert Astals Cid <aacid at kde.org>:
> El Dijous, 18 de setembre de 2014, a les 22:31:08, Gilles Caulier va escriure:
>> 2014-09-18 21:39 GMT+02:00 Albert Astals Cid <aacid at kde.org>:
>> > El Dijous, 18 de setembre de 2014, a les 07:01:32, Gilles Caulier va
> escriure:
>> >> 2014-09-17 20:36 GMT+02:00 Albert Astals Cid <aacid at kde.org>:
>> >> > El Dimecres, 17 de setembre de 2014, a les 15:07:59, Tobias Leupold va
>> >> >
>> >> > escriure:
>> >> >> Hi list!
>> >> >>
>> >> >> I'm from the KPhotoAlbum project. We recently introduced support for
>> >> >> face
>> >> >> detection and face recognition using libkface. Likely, this will be a
>> >> >> part
>> >> >> of the next release. Actually, we are the first project apart from
>> >> >> Digikam
>> >> >> (who initiated and maintain libkface) to use libkface.
>> >> >>
>> >> >> This leads to a problem: at the moment, libkface is distributed with
>> >> >> the
>> >> >> Digikam sources. There's an own git repository for the lib's sources
>> >> >> in
>> >> >> the
>> >> >> KDE repositories, but there's no own release.
>> >> >>
>> >> >> Some distributors (e. g. Gentoo) have an own package for libkface
>> >> >> nevertheless, others don't (e. g. Debian). So, at the moment, we would
>> >> >> have
>> >> >> to include libkface in our sources, as Digikam does (which would lead
>> >> >> to
>> >> >> collisions if both KPA and Digikam would be installed and is perhaps
>> >> >> not
>> >> >> a
>> >> >> good idea) or we would have to pull the full Digikam package as a
>> >> >> dependency if the user wants libkface support.
>> >> >>
>> >> >> Both "solutions" don't seem to be nice.
>> >> >>
>> >> >> Thus, Gilles Caulier from Digikam suggested to move libkface into
>> >> >> kdegraphics/libs, so that it will be included into the normal KDE
>> >> >> release
>> >> >> cycle and will be independent of Digikam, cf. the discussion on the
>> >> >> Digikam
>> >> >> mailing list:
>> >> >>
>> >> >> http://mail.kde.org/pipermail/digikam-devel/2014-September/075737.html
>> >> >>
>> >> >> He said I had to ask the kdegraphics mailing list if the admins would
>> >> >> also
>> >> >> agree to do so.
>> >> >>
>> >> >> So what do you think?
>> >> >
>> >> > I don't think adding to kdegraphics/libs is needed, you can just make
>> >> > independent releases from it's current living position at
>> >> > extragear/libs,
>> >> > no?
>> >>
>> >> digiKam team will not made an independent release of this library.
>> >
>> > Collaboration \o/ oh :-/
>>
>> Excuse me to shared and maintained this library. If this not enough...
>
> That's not collaboration, that's development which is awesome.
>
> But really, if you want others to use your libraries you have to release them
> in a way they are usable by others.

But it's already the case no ? Through kdegraphics/libs it's the
better way that i know to share with other KDE application.

Code is well documented, tested, and maintained since many years now...

>
>> >> We have do it in the past with libkipi, libkexiv2, and libkdcraw, and
>> >> it's the hell and time consuming. This is why these libs are hosted in
>> >> kdegraphics/libs since a while.
>> >
>> > And we've had countless problems with them because you kept changing them
>> > ignoring all the rules we have for libs in kdegraphics/libs
>>
>> Ah, which one exactly ?
>>
>> We take a care about BC and KDE release plan.
>>
>> > and shipping them
>> > as part of your "digikam SC"
>>
>> Not totally true. There is a flag in digiKam SC root cmake file to
>> exclude libkipi, libkexiv2, and libkdcraw of compilation and use
>> system based libs. This one is used by packagers.
>
> Ok, i may have been misinformed.

Look here :

https://projects.kde.org/projects/extragear/graphics/digikam/digikam-software-compilation/repository/revisions/master/entry/CMakeLists.txt#L43

As you can see, option is disabled by default.

>
>>
>> >> If the same rules about libkface can be done to share publicly this
>> >> API with other KDE applications, this will be perfect and homogeneous.
>> >
>> > Anyway this is not the place to ask for a new module to be added to a
>> > stable release, i'd say kde-core-devel is or release-team.
>>
>> If to include libkface in kdegraphics/libs is too problematic (as i
>> suspect), we can do better for KF5 : drop libkexiv2, libkipi, and
>> libkdcraw from kdegraphics and that all. Like this, you can be sure
>> that all will be clean from my side in kdegraphic/libs...
>
> And would all the programs that use those libraries do if there's no release
> of them?

of course. It's a weird way i'm sure (:=)))...

I'm try to be always constructive, but you must understand that in the
past, digiKam team has release separately all libraries to share with
others KDE applications, and this have been the heel to manage. The
time taken to release separated tarballs have been a time consuming.
For each libs, a precise release plan with a lots of constrains which
have slow down digiKam development (which has more than 10 years now).

I'm agree to share and i know all constrains about to release
libraries, but this must still humanly acceptable for maintainers and
developers.

Gilles