patchFreeciv - Patches: patch #3719, Distributing cimpletoon .blend...

 
 
Show feedback again

patch #3719: Distributing cimpletoon .blend sources

Submitted by:  Marko Lindqvist <cazfi>
Submitted on:  Tue 19 Feb 2013 05:09:07 AM UTC  
 
Category: NonePriority: 5 - Normal
Status: DonePrivacy: Public
Assigned to: Jacob Nevins <jtn>Open/Closed: Closed
Planned Release: 2.4.0, 2.5.0, 2.6.0

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat 08 Feb 2014 05:48:27 PM UTC, comment #17:

> I might also use the same docs and procedure for 2.3.5, when
> that happens.

Remembered to do this (just about).

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 08 Feb 2014 01:19:50 PM UTC, SVN revision 24392:

Document distribution policy for original graphics materials.

Requested by Marko Lindqvist (cazfi@gna).

See gna patch #3719.

(Browse SVN revision 24392)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 08 Feb 2014 01:18:49 PM UTC, SVN revision 24391:

Document distribution policy for original graphics materials.

Requested by Marko Lindqvist (cazfi@gna).

See gna patch #3719.

(Browse SVN revision 24391)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 14 Sep 2013 03:11:46 PM UTC, comment #14:

Release procedure updated.

As an example, here's the 2.4.0 graphics tarball.

I might also use the same docs and procedure for 2.3.5, when that happens.

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 14 Sep 2013 03:01:55 PM UTC, SVN revision 23373:

Document distribution policy for original graphics materials.

Requested by Marko Lindqvist (cazfi@gna).

See gna patch #3719.

(Browse SVN revision 23373)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 14 Sep 2013 02:55:47 PM UTC, SVN revision 23371:

Document distribution policy for original graphics materials.

Requested by Marko Lindqvist (cazfi@gna).

See gna patch #3719.

(Browse SVN revision 23371)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 14 Sep 2013 01:08:51 PM UTC, SVN revision 23369:

Document distribution policy for original graphics materials.

Requested by Marko Lindqvist (cazfi@gna).

See gna patch #3719.

(Browse SVN revision 23369)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 14 Sep 2013 01:07:40 PM UTC, SVN revision 23368:

Document distribution policy for original graphics materials.

Requested by Marko Lindqvist (cazfi@gna).

See gna patch #3719.

(Browse SVN revision 23368)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 14 Sep 2013 01:06:39 PM UTC, comment #9:

> We'll need to modify the docs that go in the regular tarball to
> point out the existence of this extra one (and what it's for).

Attached some documentation changes, which I will commit immediately as part of the 2.4.0 release. Sorry for lack of review period.

For 2.4.0, I intend to use a manual procedure similar to that described in comment #5.

(file #18988)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Thu 12 Sep 2013 11:44:09 PM UTC, comment #8:

In short, the problem is in how the main tarball then would not depend on gfx -tarball. Most obviously main tarball's "./configure && make dist" cannot build gfx -tarball when gfx is not present.

Marko Lindqvist <cazfi>
Project Administrator
Thu 12 Sep 2013 11:17:16 PM UTC, comment #7:

> How hard would it be to drop a suitable tarball out of
> "make dist"?

The short answer is apparently "quite hard", so I shouldn't wait for this to appear to solve this problem.

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sun 11 Aug 2013 02:59:35 PM UTC, comment #6:

I've let this slide for 2.4.0-RC1, but we should do something about it for 2.4.0.

How hard would it be to drop a suitable tarball out of "make dist"? It's generally a good idea to avoid manual steps in release processes.

Since downstreams such as Debian may wish to assemble comprehensive source tarballs, I think the "graphics" tarball should have the same path structure as the regular source tarball (i.e., paths should be freeciv-2.4.0/data/graphics/...) so that it's unambiguous how to correctly reassemble them.

We'll need to modify the docs that go in the regular tarball to point out the existence of this extra one (and what it's for).

(I'm not really looking forward to uploading another huge tarball every release, since my Internet connection is made of damp string and that's. But that's my problem, really.)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sun 05 May 2013 11:57:48 PM UTC, comment #5:

I'm practically following the Debian logic here in that I'm concerned about "preferred form of modification" (which is practically the definition of "source code" in GPL). Specifically it doesn't matter that we don't have scripts to automatically run blender, any more than project where compiler is run by manual commands can omit releasing C-sources.

So, I'm suggesting to add release managers workload with something like:

> svn export svn://svn.gna.org/svn/freeciv/tags/R2_4_0/data/graphics freeciv-graphics-src-2.4.0
> tar cjf freeciv-graphics-src-2.4.0.tar.bz2 freeciv-graphics-src-2.4.0


Upload to sourceforge

Marko Lindqvist <cazfi>
Project Administrator
Sun 28 Apr 2013 09:12:21 AM UTC, comment #4:

Something I have seen done for other projects in the past is to distribute a separate tarball with large assets used to generate graphics, textures, sounds, etc. in the same distribution locations. This has the advantage of making it easily available to those who want it, but not forcing everyone to use it.

The occasional practice in Debian of ensuring all sources are present as part of the distributed tarball comes from being extra careful about the "preferred form for modification" clause in the GPL. Only by building the distributed binaries from the modification sources can one be certain that the distributed object code can be reliably reproduced from the modification sources (and consequently that any recipient can easily/safely modify the result to match their tastes) using the Debian system (this also acts as a test of any dependent tools: for example, if blender were an essential part of the workflow, it would be extra annoying for Debian users if the blender included in a given release of Debian couldn't reprocess the graphics for some other package in that release). This definition of "source" is not hardened in Debian policy, so that if freeciv declares that although these materials may have been used as part of a generation process, that generation process was in part manual, and the (smaller) graphics actually used by the game are the preferred targets for modification, that would likely be honoured. That said, the same logic that drives this practice may apply in other environments.

Anyway, looking at data/graphics, we don't seem to have any build system instructions that can produce the png files from the blend files, making me think that the blend files aren't actually "source code", but rather "materials" used by the artists in the construction of the "source code" png files. Mind you, that's only my opinion, but were I handling the release, I'd probably only reference source control or maybe provide a tarball, but avoid calling the blend files "source code" as much as possible. Alternately, if they are already considered "source code", there should be automake hints that allow one to regenerate the graphics files from the blend files, and then they should definitely be in the tarball.

Emmet Hikory <persia>
Project Member
Mon 18 Mar 2013 11:20:45 PM UTC, comment #3:

From our COPYING:

3a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

3b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

...

If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

-----------

Note word "complete" for source code to distribute. Making them available from the same place as (windows) binaries would mean having them in sourceforge.

Marko Lindqvist <cazfi>
Project Administrator
Fri 22 Feb 2013 11:19:07 AM UTC, comment #2:

> There is precedent


That doesn't mean it has been handled perfectly, though.

My interpretation is that at least documentation in tarball should tell where the sources are easily available, and that is entirely sufficient (GPL doesn't require one to automatically push out sources at all - promise to provide them for someone asking for them is enough) I'm not entirely sure about Debian policy, but at least with some packages they have wanted to put everything like this to their source packages, so README.packaging would be one place to mention these.

Marko Lindqvist <cazfi>
Project Administrator
Fri 22 Feb 2013 10:49:35 AM UTC, comment #1:

There is precedent for not distributing components from which distributed graphics were derived. For instance, data/graphics/ in svn comes to 98Mbyte(!) and contains huge originals for buildings, wonders etc.

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Tue 19 Feb 2013 05:09:07 AM UTC, original submission:

Currently cimpletoon unit .blend files are not put to tarball.

I'm not really into adding them there, either. Most people wanting just to compile freeciv wouldn't want size of the tarball to grow with these files. Of course putting them to tarball would be most idiot-proof way to distribute them in a GPL compliant way.

Should we package them separately? Could we go by only pointing to our version control in documentation?

Marko Lindqvist <cazfi>
Project Administrator

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #18988:  S2_4-graphics-readme.patch added by jtn (2kB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one

Digest:
   task dependencies.

 

Carbon-Copy List
  • -unavailable- added by persia (Posted a comment)
  • -unavailable- added by jtn (Posted a comment)
  • -unavailable- added by cazfi (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 14 Sep 2013 03:11:46 PM UTCjtnStatusIn Progress=>Done
      Open/ClosedOpen=>Closed
      Planned Release2.4.0, 2.5.0=>2.4.0, 2.5.0, 2.6.0
    Sat 14 Sep 2013 01:06:39 PM UTCjtnAttached File-=>Added S2_4-graphics-readme.patch, #18988
      StatusNone=>In Progress
    Sun 04 Aug 2013 07:25:30 PM UTCcazfiAssigned toNone=>jtn
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup