Re: Red Eclipse should be in main
This is a long email so I've summarised it here, my arguments boil
down to these points:
Debian users should have the same freedoms wrt all works in Debian
main, be they art, programs, docs or works that blur the lines between
all three (aka games).
Debian users and upstream developers must have equality of access to
the digital bits that make up a work. Users using only Debian main
must be able to modify the work in the same way as upstream and
build/run the full modified work.
The only way to determine if that is the case is to use critical peer
review and build as much as possible from source. Where something
isn't practical to build from source on every package upload (say it
takes 3 weeks to render), not building from source is acceptable as
long as it is manually verified to be buildable at least once and at
best once per upstream release.
On Tue, Mar 4, 2014 at 7:53 PM, Markus Koschany wrote:
> I am afraid but you don't give neither an exact definition of the vague
> term "upstream development practices" nor do you try to explain with
> concrete examples in regard to other games in main why Red Eclipse is
> unsuitable for Debian.
I wasn't arguing that Red Eclipse is unsuitable for Debian main, not
sure why you appear to think that.
I was arguing that we don't yet know if Red Eclipse is suitable for
Debian main because the investigation required hasn't yet been done.
>From past experience I've found that for almost any upstream, if you
use a critical eye on their "source tarballs" and talk to them about
how they develop their code and data, you will find missing source
(aka upstream's preferred form for modification, which DFSG item 2
requires) and usually find out where that source is located. It is a
very rare upstream that gets this right, for example even the FSF got
it wrong on emacs (more examples in my other mail). I don't think it
is acceptable to take upstream tarballs as-is unless there are no
files that might indicate missing source. The important thing is to
check.
> I really believe that your personal upstream guide is a valuable
> reference guide for everyone who wants to create artwork.
That is exactly what it is intended as. It is a good way for upstream
game/art projects to remain viable and not require (for example)
completely redoing videos from scratch just to increase the resolution
to 4K when upstream disappears and all you have are the upstream
tarballs from snapshot.debian.org. I've been in similar situations
with several games I became upstream for and some of them still have
problems like this (chromium-bsu 3D text for example).
It is also a useful guide for those who are auditing upstream tarballs
and want to ask upstream what the source for certain possibly suspect
files is.
> However it is neither the ftp-masters reject FAQ nor part of Debian's policy.
The reject FAQ is not comprehensive. For example it doesn't mention
obfuscated JavaScript and they routinely reject packages due to that.
Debian policy doesn't say anything about what is suitable for main or
not, that is determined by the DFSG in general and the ftp-master's
interpretation of the DFSG in practice.
> If you think this personal guide through to the end, then all games are
> unsuitable for main and I suppose that's what nobody in this team really
> wants.
I very much disagree with this line of thinking. The DFSG is what
determines if something is suitable for main. The guide is also useful
when auditing upstream tarballs.
Let me give you an analogy from a different side of the digital world...
If you find a package entirely composed of x86 assembler under the MIT license.
The build process runs GNU as and ld to convert that assembler to
object files and an ELF executable.
All good and fine right?
Assembler isn't popular these days so you feel a bit strange about
packaging it but it has a free license so you upload it anyway.
Someone who knows a bit more about programming finds a bug and as a
consequence looks at the code.
They find that the assembler is not actually the source. Upstream has
used a compiler to generate assembly and shipped that as the source.
You talk to to upstream and find out their C code isn't yet published.
You finally convince them to release it. It requires a non-free
compiler to build but you port the broken parts to GCC fairly easily
and upload it to fix the DFSG violation.
Upstream makes a new release that changes some of the code and
rewrites a file. You upload without checking the changes since you
decide to trust upstream.
Someone finds a new bug in the parsing code which was in rewritten
file and sees that the rewritten code went from handwritten C code to
C code generated from some other code that upstream didn't release.
Yay, another DFSG violation.
This exactly the kind of things that the guide to data source can help
you prevent.
>From my personal experience being a Debian member since 2006 and a
sponsored packager for a while before that, for the initial upload,
every upstream release and transitions from non-free to main, it is
important to check every file/updated file. This is the responsibility
that people creating and sponsoring Debian packages take on.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: