Bug#1085121: RFS: quadrilateralcowboy/0~20240909.git3e3947707-1 [ITP] -- first-person cyberpunk adventure game

[James Addison]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "quadrilateralcowboy":

* Package name : quadrilateralcowboy
Version : 0~20240909.git3e3947707-1
Upstream contact : James Addison <***@jp-hosting.net>
* URL : https://www.blendogames.com/qc/
* License : Expat, public-domain, SGI-B-1.1, BSD-2-clause,
Khronos, LGPL-2, Zlib, GPL-3.0-with-additional-id-terms, RSA-MD
* Vcs : https://salsa.debian.org/jayaddison/quadrilateralcowboy/
Section : contrib/games

The source builds the following binary packages:

quadrilateralcowboy - first-person cyberpunk adventure game

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/quadrilateralcowboy/

Alternatively, you can download the package with 'dget' using this command:

dget -x https://mentors.debian.net/debian/pool/contrib/q/quadrilateralcowboy/quadrilateralcowboy_0~20240909.git3e3947707-1.dsc

Changes for the initial release:

quadrilateralcowboy (0~20240909.git3e3947707-1) unstable; urgency=medium
.
[ James Addison ]
* Initial release. Closes: #1026277

Regards,

[James Addison]

Hi Phil,

[ ... snip ... ]
This package uses a fork of the upstream github repo. Is there a particular
reason for not using it?

Primarily this is to build against a source that includes additional
modifications, and removes vendored library code (a Debian
best-practice, but also a general software development practice that I
tend to agree with).

Apart from the vendored-code removal, I've offered each modification
within pull requests to upstream, with mixed results that I expect may
be due to the fact that it isn't worth the time/effort for the
developer to review and apply them all (the game was released nearly a
decade ago, and the developer is working on other titles).

On a related note: the homepage field for the package contains a
hyperlink to the game's webpage on the developer website, instead of a
link to my fork of the codebase on GitHub. This is somewhat
intentional, because players will require the corresponding game data
(hence the package is assigned to the Debian contrib section), and
that game data is available for purchase from the developer.

Regards,
James

[Soren Stoutner]

Typically, in Debian packaging, you would use Files-Excluded in debian/
copyright to remove things like vendored library code, and debian/patches to
make modifications that have not yet/are not likely to be accepted upstream.

For example, see:

https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/
copyright?ref_type=heads

https://salsa.debian.org/cryptocoin-team/electrum/-/tree/master/debian/
patches?ref_type=heads

Post by James Addison
Hi Phil,

[ ... snip ... ]
This package uses a fork of the upstream github repo. Is there a particular
reason for not using it?

Primarily this is to build against a source that includes additional
modifications, and removes vendored library code (a Debian
best-practice, but also a general software development practice that I
tend to agree with).
Apart from the vendored-code removal, I've offered each modification
within pull requests to upstream, with mixed results that I expect may
be due to the fact that it isn't worth the time/effort for the
developer to review and apply them all (the game was released nearly a
decade ago, and the developer is working on other titles).
On a related note: the homepage field for the package contains a
hyperlink to the game's webpage on the developer website, instead of a
link to my fork of the codebase on GitHub. This is somewhat
intentional, because players will require the corresponding game data
(hence the package is assigned to the Debian contrib section), and
that game data is available for purchase from the developer.
Regards,
James

[James Addison]

Post by Soren Stoutner
Typically, in Debian packaging, you would use Files-Excluded in debian/
copyright to remove things like vendored library code, and debian/patches to
make modifications that have not yet/are not likely to be accepted upstream.

Thank you, Soren. I'm considering what to do about this.

In some ways it would be nice to solely use patches and
file-exclusions for the Debian packaging here -- on the other hand, if
I want to develop and forward future modifications to upstream (and
that, I think, will be my default approach, even if the patch
acceptance rate is unpredictable), then the standard GitHub workflow
is to initiate those as pull requests from fork(s) of the source.

Additionally, I have in mind that I don't think it's yet clear in this
case whether my fork is a continually and actively maintained
development derived from the original (a clear candidate for upstream
status), or simply a place where a few patches have been applied and
collected (a more ambiguous situation).