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

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 15 January 2015 17:48:16 Thiago Macieira wrote:
> On Friday 16 January 2015 01:38:50 Kevin Kofler wrote:
> > What we do not have guidelines for so far is reuse of systemwide
> > JavaScript
> > libraries in non-web applications. So Qt will probably get away with
> > bundling three.js for now. But shipping it only in minified form is also
> > banned by global Fedora policies and thus clearly unacceptable.
> 
> To clarify: minified-only is obviously bad.
> 
> But what if we ship source and the generated minified files?

We (Debian) need to remove the minified sources from the original tarball.

> We do that for other sources that seldomly change, like the outputs from
> qlalr. We also ship generated docs and the generated include/ headers.
> That's for ease of building, not for hiding anything. Remember we have
> trouble even asking for Perl to be present during build.

Before answering this one please note that I understand why you do this and 
why you would prefer to keep doing it. It happens that distros like Debian 
(and for what I read, also Fedora) think differently.

I realize we in Debian might be missing to regenerate some stuff (maybe quite 
a lot) but when we find stuff that has been pre-generated we do our best to re 
generate it during the build process.

Doc is an example, we Debian maintainers need to ensure that every piece we 
ship is in it's preferred form of modification and that we are able to create 
the resulting stuff ourselves with the tools in the archive. So pregenerated 
doc is not a solution for us.

There are exceptions with stuff that can be used on all archs (like docs, 
called "arch: all" in Debian's jargon) but those are probably going to 
dissapear once arch:all packages are built on Debian's infra.

Anyone: if you find something that needs regenerating and we (again, Debian) 
are not doing it, do not hesitate to fill a serious bug in Debian's bug 
tracker. Or ping me if you somehow find it and you are not using Debian.

> If that's ok, does it matter that a non-free tool was used? I'm guessing it
> does matter, even if there's a free one can also produce a valid output.

Yes it does matters, totally. Requiring a non-free tool to build would make Qt 
and **everything** that depends on it to the contrib repo: free software stuff 
that needs non-free stuff to build and/or run. And that supposing we can ship 
the build tool in non-free, else we would simply not be allowed to build that 
part.

If there is a free tool which can be used instead of the non-free one we will 
do our best to use it, even if the result is sub-par. Else we would prefer to 
simply remove the offending file and tell our users "sorry, but it needs a 
non-free tool to build". Putting Qt in the contrib repo is a much worst user 
disservice than not shipping the file (and again, in Debian terms).

As a side note, Debian's rules are also Ubuntu's ones for most of their stuff, 
including Qt.

-- 
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/20150116/d020cf2c/attachment.sig>