Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game
Followup-For: Bug #1026277
There are a bunch of mistakes that I've made along the way while attempting to
package this game. Some that I'd note are:
* I could've made more of an effort and waiting longer for upstream contact
before listing an upstream email address (sorry for any resulting spam
received at the Blendo Games domain!).
* Related, I could've made clear that I was the upstream source code provider
instead of leaning on an ambiguous Salsa-as-both-origin-and-package-VCS for
a while.
* The number of package uploads to mentors.debian.net was large and noisy;
I was iterating fairly quickly on improvements and adjustments, and had not
yet discovered all the linting utilities available and how to run them
locally.
* Version history is somewhat unclear - there is a mix of what I would call
the 'upstream' version numbers (timestamps in the format YYYYMMDD) - these
are what I have used to tag upstream versions of the code (where no
packaging information exists) and 'package' version numbers (these include
single-digit prefixes, plus a package-version suffix).
This is most relevant in the case of the 20160725 release, which I think
could be the point at where my upstream version begins to more-clearly
diverge from the original Blendo Games codebase (by the addition of a
second architecture).
As part of the packaging process, upstream version 20160725 became version
0~20160725-1 of the package, and I'd consider the changes between there and
1~20160725-1 to be Debian-related: they weren't particularly relevant to my
identity as upstream developer, but they did help the package become more
applicable to Debian's architectures (not all, unfortunately, but I think
that adding support for a second runtime architecture can be a big step
for compiled software).
That change, and the change to add a manual, have been included into the
'upstream' codebase. Strictly speaking, the additional architecture
support probably should've been a patch, followed by merge upstream,
followed by inclusion and then patch-drop in the package. They have been
offered to the 'original upstream' codebase, for possible integration there
if that's something that Brendan / Blendo Games would find useful.
I guess that some remaining confusion arises from the fact that despite
me managing both upstream and Debian packages currently, there are still
patches in the 'debian/patches' directory. That does seem odd to me and I
should probably take another look at including those into the upstream
codebase. I think my original plan with those was to gradually offer them
to 'original upstream' and drop them from the Debian package if-and-when
accepted. Trying to remember/figure out my logic for why not all of them
are offered upstream.. my best guess is that I've only offered ones that I
think were unlikely to cause compatibility difficulties (so changing file
paths, for example, is _not_ offered upstream) with the original. But I
could be retroactively making that up.
* Insufficient testing on the second architecture port - I got it running
incredibly slowly in an emulator -- enough to confirm that it runs,
basically, but not more than that.
* My release signing has been inconsistent, partly because I'm not sure I
have a long-term commitment to being a Debian Maintainer/Developer, and
partly because I'm not sure I can reliably keep those keys secure (so, at
best I think they would provide some integrity verification support, but
I don't think they really attest highly that I'm the sole or uncompromised
author). Not a particularly useful mindset to have, some might argue, but
it does lead to me towards using ephemeral keypairs (somewhere, once, I had
some web-of-trust identity, but I haven't continued to use or maintain it).
All of these are avoidable problems - and in fact most of them are documented,
but I found it tricky to find all of those details and to keep them in mind;
even now I expect I would notice and learn more when reading through the
packaging guidelines again. Generally it's been a good learning experience
though. If any of the problems with the package make it ineligible for some
reason, that's a shame, but I can manage. Otherwise, I'll be glad to fix
things up where required and think about ideas to make those problems less
likely for others to encounter (without reducing resulting package quality).
Reply to: