|| ||Joey Hess <joeyh-AT-debian.org> |
|| ||585409-AT-bugs.debian.org |
|| ||this bug .. bugs me |
|| ||Tue, 5 Jun 2012 11:52:52 -0400|
|| ||Article, Thread
10 Jun 2010 a bug was filed wanting wine 1.2 packaged in time for squeeze.
12 Aug 2010 packages of 1.2 were available .. but not in Debian.
6 Feb 2011 squeeze shipped with the same wine version that shipped in lenny.
7 Mar 2012 wine 1.4 was released as the new upstream stable release
25 May 2012 wine 1.2 was finally made available in unstable
I've read over this entire bug, and while there are clearly some hard
problems and a lot of good work shown here, I'm seeing a concerning
trend throughout it.
We seem to have a problem with being willing to trade off simple
solutions that will greatly benefit users, for doing things "right",
even when doing things "right" benefits users *less*.
Examples of that seen in this bug include:
* An idea that every old release of wine needs to be packaged in sequence,
so it'll be available in snapshots, so users can pull down an old
version as needed for maximal ability to find one that works. That's
the theory, the actual end result is that users had no modern
wine version at all to use, for many years.
This is a simple tradeoff of benefits to sets of users,
and the set of users who know how to use snapshot.debian.org, need
a two year old version of wine there, and can find the right version is
clearly much smaller than the set of users who would like the latest
wine to see if it runs some program.
* Wanting to support multiarch coinstallability, plus wine and
wine-unstable coinstallability. Nice goal, but again it prioritises
some small set of users who need 2 or even 4 versions of wine
coinstalled over the larger set of users who just want the newest wine
* Not using existing Ubuntu packages of wine despite them being
available for a long time at newer versions.
* People doing work allowing themselves to be blocked for a long time on
some minor procedural point, like whether they have commit access to a
particular git repository, or are not being added as a member of some
particular team, or whether infrequent and apologetic posts by a package
maintainer are enough to keep them from being considered MIA.
This bug is a textbook example of making the perfect the enemy of the good.
It's disconcerting that we, or our users, are willing to put up with this.
see shy jo
to post comments)