Re: quality assurance for games
Jon Dowland wrote:
> On 14 Dec 2012, at 11:46, Emmet Hikory wrote:
> > Similarly, if something is buggy (but fixable), or
> > otherwise needs several hours of work to get into shape, that oughtn't
> > be enough to remove it:
>
> Disagree, if buggy and nobody is fixing, the default should be for it to go. Not immediately, but within a process with a deadline, which should be noisy to raise awareness of the default outcome.
This is something I find demotivating, especially if the process is noisy
or complicated: when the total volume of human effort (including the effort
for all of us to read the various notices) to remove something exceeds the
total volume required to fix, it ought be fixed, rather than removed. For
example, if we have a game that segfaults under some known conditition, we
should fix it, rather than removing it, even if nobody happened to notice
the bug for some time, because nobody feels direct responsibility for the
game. Similarly, if a game is N versions behind upstream (and perhaps for
N years), we ought pull the new upstream, rather than removing it.
While I'm interested in Debian being a repository of excellent software,
I feel that the more we remove simply because we don't happen to have an
expert willing to take full, complete, and personal responsibility for
something, the less relevant we become, and the more we encourage fragmentation
and use of third-party archives to resolve the apparent lack.
> > the process of adding software to Debian is
> > entirely opaque to most users (and in some cases confusing even to those
> > of us who have been doing it for some time),
>
> This is a bug that should be fixed, not worked around.
>
> > and an orphan report isn't likely to come to the notice of those
> > who use the software most: only DDs and those who act like them actually
> > pay any attention to what is orphaned)
>
> Another bug to fix. Both are hard bugs.
Indeed: these are certainly bugs, and should be fixed. That said, until
they can be addressed, I fear that any process that defaults to removal is
likely to decrease the chances that we maintain things well, rather than
increase it. When we receive feedback from someone that something is buggy,
and we don't have a currently motivated person to fix it, this is an
opportunity to gain a new team member. Conversely, when things are removed
from the archive, this is an opportunity to demonstrate that Debian no longer
has the software a given user wants, and that they should seek alternatives.
> > . And lastly, (and game-specifically),
> > when a given package provides a unique plot of some sort, it should only
> > be removed in exceptional circumstances, as if it is old with inactive
> > upstream, it is unlikely to be revived, and we lose a piece of our culture
> > when we drop it from Debian (which may be the last remaining place one can
> > download a tarball).
>
> I think cultural preservation is an admirable goal but not one that the Debian os is designed to address, nor should it. Another solution is needed. Snapshots is a good workaround. Perhaps an attic/archive repo. I'm not sure. I care about cultural preservation and the Debian os, I don't want one compromising the other.
There are any number of packages in the archive for which Debian is the
best source of raw archives (something that is often used by other
distributions, many of whom reference ftp.debian.org for upstream tarballs
(e.g. slackware uses Debian as upstream for docbook)). I haven't checked
to see how many of the Games Team packages fall into this category, but
I think that if we do not wish to continue to support the idea that Debian
has everything, we should consider that another bug, to be fixed along with
those above (or at least investigate the impact removal of a given package
has on a wider community) prior to removing these.
> > Even in these situations, one should take some care: for example, the
> > adonthell developers have moved to mostly working on Dun Barethsol, but
> > that doesn't make Waste's Edge any less playable or enjoyable (yes, there
> > are bugs, and yes upstream only cares in a limited way
>
> I think what matters is the union of upstream and maintainers here. Abandoned upstream is a warning sign rather than a guarantee of a low quality package. If the maintainers become de facto upstream, fine, IMHO.
While I agree with all of your statements here, I'm not sure that my
example was clear enough: in the case described, if the maintainers were
to become de facto upstream, it would mean a local fork of the package,
perhaps with two different adonthell packages in the archive, one for
each scenario. Rather, I don't think we should remove the game (and engine)
from the archive just because upstream is working on an entirely different
scenario, and that this case is distinct from cases like the evolution of
strategus into boswars, where strategus became an obvious candidate for
removal, where upstream had moved to new branding and engine (and the new
version was in the archive in parallel).
This difference is important in two ways: firstly that other providers
of data for the engine would be unable to continue their game development
in the prior case, whereas there is (very limited) engine porting in the
latter, and secondly that we would do best to ensure that we have replacements
in the archive prior to removal, to provide continuity and the opportunity
to warn users that they would need to migrate their {data,habits} as part of
the upgrade to the latest debian release.
--
Emmet HIKORY
Reply to: