[Development] Policy: supplying the preferred format for modifications for everything we ship

Thiago Macieira thiago.macieira at intel.com
Sun Sep 29 22:31:11 CEST 2013


On domingo, 29 de setembro de 2013 20:17:09, Knoll Lars wrote:
> I don't fully agree with this.
> 
> I certainly don't want us to add huge amounts of data into our
> repositories (as e.g. high resolution vector images). IMO it simply makes
> more sense to clearly state how you can get the data from upstream.

I didn't say "add to the repositories". But we need to have a copy of them in 
our infra. We could just add the files to our download server, in a special 
area.

> In addition, I prefer not to copy upstream data if we can avoid it.
> Duplicating upstream data can also be harmful. I've seen patches appear in
> that data before that then do not get submitted back upstream (e.g. in our
> copy of libpng or harfbuzz).

Agreed. If possible, don't have third-parties in the first place. Require them 
from the system.

Unfortunately, that reasonable request is not reasonable on Windows.

> At most we should have a readonly copy of the sources on our FTP server,
> but I am not sure this really gives any benefits if what we use is a
> straight copy of an upstream package.

That's what I am asking.

The benefit is that we still have the original sources, should the upstream 
disappear and close down. Also, I believe this is required in order to fulfill 
our obligations under the LGPL: that's why every company shipping an Android 
device must have a copy of the kernel sources in their servers and it's not 
enough to point to kernel.org.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- 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://lists.qt-project.org/pipermail/development/attachments/20130929/49f74ddd/attachment.sig>


More information about the Development mailing list