Re: quality assurance for games
On 15-12-12 00:33, Emmet Hikory wrote:
> Jon Dowland wrote:
>> 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.
That's a nice theory, but you can't allocate other people's time. If
people want to spend their time talking about bugs, but not fixing them,
you can't stop them. The fact that a lot of time is spent talking about
a bug doesn't mean you can undo that and make the bug fixed instead. In
the end, someone will have to actually go and fix the bug. If nobody
does that, the bug is not fixed. If after several warnings that a
package will be removed if a bug doesn't get fixed, still nobody steps
up to do it, then the conclusion must be that nobody is interested
enough in the package to spend time on fixing it, which means it is too
low quality to be in Debian (due to the bug), and it should be removed.
You seem to want Debian to include all existing free software. I don't
want that. If I install a package from the official Debian archive, I'm
expecting a certain level of quality. And in stable releases, the level
should be higher than in unstable. If I have a stable system, and I
install an official package, I expect it to work and to not break other
software on my system. Packages that can't meet those criteria should
not be in a stable release.
> 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.
We shouldn't silently remove things which have open RC bugs, indeed. We
should noisily and slowly remove them. If the noise awakens someone who
cares enough to fix the bug (for which we give plenty of time), then we
don't remove it. But if nobody cares enough, the package should go.
> 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 goal is to have all good software in Debian. And the maintainer
doesn't have to be such a superman. He or she can also ask around in
case a bug that they can't fix themselves is found. But yes, the
maintainer should take personal responsibility that bugs get fixed. Not
to personally fix them, but to make sure that they get fixed. If nobody
steps up to do that job, then the software can't be so important.
>>> 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.
It would be, if it was true. What's hard about it? Anyone with (full)
upload rights to the archive can upload new software. It will be
checked, which takes some time, but there's nothing hard about it. All
you have to do is wait (and fix problems if ftp-master finds any).
>>> 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)
This is true; perhaps package managers should warn when you are trying
to install an orphaned package, or a package with open RC bugs.
> 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.
This is why the removal process should be noisy. If the bug reporter is
able to fix things themselves, they must be given the chance to do so.
But if they can't (or won't) and nobody else does, then all we have is a
buggy package, which doesn't meet the quality standards that Debian
wants to have.
> 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.
Indeed. And that is something we don't want. But having a package with
bugs in the archive is also something we don't want. I'm not saying
removing packages is a pleasant thing. But it can be a good thing in
some cases, even if it is unpleasant.
> 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.
Debian never claimed to have everything, and I'm pretty sure we don't
want to claim it either. As for the museum functionality, AFAIK that's
an unintentional feature. With archive and snapshot servers, we're doing
a great job at it, though. And we're doing that job without keeping the
packages in every release, too. I don't see how this is an argument for
keeping the packages in unstable (and every new release we do). We have
backups of old releases. If people want to point to files that used to
be in Debian, they can. There is no problem there.
Thanks,
Bas
Reply to: