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

Knoll Lars Lars.Knoll at digia.com
Sun Sep 29 22:17:09 CEST 2013


On 9/29/13 9:56 PM, "Thiago Macieira" <thiago.macieira at intel.com> wrote:

>>From the Minified javascript thread, I propose this policy:
>
>The Qt Project will always supply in its own infrastructure the preferred
>sources for modification for whatever we ship. Under the GPL and LGPL,
>anyone 
>who receives our sources and wishes to redistribute is required to do
>that 
>anyway. Whether the same sources are present in our regular tarballs or
>not, 
>it should be judged on a case-by-case basis.
>
>For most of our own content, that is easy: we've been doing that since
>time 
>immemorial.
>
>For any third-party content, we need to have the correct scripts to
>recreate 
>the files. 
>
>Examples:
>
>Qt binary releases		=> source tarballs
>Qt Documentation		=> source tarballs
>pre-generated lexers and parsers => source files (.g, .l, .y)
>Images					=> original, high-resolution or vector images
>Minified JS scripts		=> original, un-minified scripts
>gnuwin32 binaries		=> gnuwin32 source tarballs

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.

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

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.

Cheers,
Lars




More information about the Development mailing list