Review Request 110962: Switch to an external LibRaw

[Pino Toscano]

Alle lunedì 8 luglio 2013, Gilles Caulier ha scritto:
> 2013/7/8 Pino Toscano <pino at kde.org>:
> > Alle domenica 7 luglio 2013, Gilles Caulier ha scritto:
> >> > On July 4, 2013, 11:15 a.m., Pino Toscano wrote:
> >> > > Ping. Gilles, can we please get rid of this libraw copy?
> >> > 
> >> > Gilles Caulier wrote:
> >> >     I'm here...
> >> >     
> >> >     In one week, it's holidays time for me (3 weeks). I will
> >> >     review this entry in-deep in mid-july
> >> >     
> >> >     Gilles Caulier
> >> 
> >> Pino,
> >> 
> >> I propose to create a libkdcraw branch, based to git/master and to
> >> to apply your patch. This will be more easy to review and fix
> >> before to switch this branch in production.
> >> 
> >> Also, just receive libraw 0.15.3 to apply on master. We can sync
> >> your branch easily with git.
> > 
> > There, "external-libraw".
> > 
> > Note that libraw and extra cmake files are not (and will not)
> > removed in that branch, to ease the eventual merging from master.
> 
> And no files must be removed for the moment.
> 
> Using an external libraw must be optional in this condition :
> 
> 1/ check if external version is available on the system.
> 2/ check if it's 0.15.x version.
> 
> if 1/ and 2/ and respected, well compile and link against shared
> version.
> 
> ...else print a warning and indicate that internal version will be
> used.

Again keeping using internal stuff? Please, pretty please, get out of 
the mindset that using a copy of an external library is a good thing, 
because it is plain wrong.

I'll be even more clearer than what I said in the review request: the 
copy of libraw inside libkdcraw must go away, ASAP.

> As libraw still in early stage of development, i would to preserve
> internal version until official 1.x release, to be able to test and
> report quickly all problem to libraw team.

Please explain how using an external version hinders testing, rather it 
is the other way round.

Using an embedded copy means people could use "two versions" of the same 
libkdcraw, one using a system libraw and the other using the external 
version. Considering how things go in such cases (also when looking at 
the history of your own handling of copies of libraries), we would run 
into situations like this: fixes are made into the embedded copy, users 
using the system version report issues and those get fixed because "the 
fix has been imported into the embedded copy" or other stuff like 
this... been there, done that, please do not get into this situation, 
really.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130708/7910cb9e/attachment.sig>