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

Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail.com
Mon Sep 30 14:38:32 CEST 2013


On Sunday 29 September 2013 13:31:11 Thiago Macieira wrote:
> 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.

AFAIU, that would be enough, yes.

> > 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.

+1 to the idea as presented here by Thiago.

-- 
Geek Inside!

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: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130930/5e14d8d3/attachment.sig>


More information about the Development mailing list