[pkg-wine-party] Bug#585409: this bug .. bugs me

[Michael Gilbert]

On Tue, Jun 5, 2012 at 11:52 AM, Joey Hess wrote:
> 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
>  version.
>
> * 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.

Not sure what to say other than when I became a DD and gained the
power to NMU, I started fixing this.  Before that, Ove's contributor
rejections blocked myself and many other non-DDs from effectively
helping.

Anyway, we've had recent threads on the continuing issues with strong
package maintenance, and from what I can tell, there is no clear
direction.  The solution I'm pursuing is a liberal application of
NMUs, and it seems to be working (albeit a bit slowly).  Do you have
ideas on other more effective solutions?

Best wishes,
Mike