[Development] Adding new third party component three.js to Qt?

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 14 January 2015 07:24:52 Keränen Pasi wrote:
> Hi Kevin and Lisandro,
> 
> I have zero experience with distribution packaging and the problems
> therein so sorry if I’m a bit lost here. Thank you Kevin for the links you
> sent, I found them informative.

No problem, it happens quite often :)

> I followed the Packaging:JavaScript link and it states "Please note that
> this section really only applies to JavaScript libraries intended for use
> on the web”. Canvas3D and three.js port on top of it are NOT meant to be
> used on the web, they are both meant to be used within QtQuick/QML
> environment, so running locally as part of your native code (or pure
> QtQuick) application.

That might be a question for Kevin, but on Debian a javascript library is 
treated as any other C/C++ library: source code should be there, the 
binary/minified version must be created from the unminified code at package 
build time (ie, when building the source code that ships it). It doesn't 
matter what uses it.

> I also read through the Packaging:No_Bundled_Libraries link. I can see the
> points made in there, but there is also a good reason why we want to
> bundle the three.js together with certain version of Qt and Canvas3D. We
> want to deliver a library that we know has been tested together with the
> V4 VM and the Canvas3D and we know it should run smoothly there. And by
> doing this we add value to our customers.

The same can be said about C/C++ 3rdparty libraries. So no, bundling is not 
good for distros. Imagine a security bug appears: we need to start hunting 
down each embedded version and fix it, checking that we don't break anything 
specially in forked cases. A nightmare.
 
> Regarding one of the points made in that document on forks. Yes, at the
> moment this port from HTML to QtQuick is a fork of the official three.js
> library and lives right next to it in Github. But as I said I’m hoping we
> can reduce the delta we have by doing some additional work on the V4VM and
> on the Canvas3D. And perhaps if the remaining HTML vs. QML delta is in
> only few places and is minimal, we can then persuade the maintainers of
> three.js to re-design those few parts to make upstreaming possible with a
> clean design.

But it's still a fork, meaning semi-duplicated code that we maintainers need 
to address.

Please allow me to be clear in one thing: I *do* understand that for Qt, as 
long as the license is respected, there is not much of a problem. What I've 
expressed here is what us distro maintainers face with this actions.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150114/3a1bf117/attachment.sig>