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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mmqh9wd7nsye8vzslrhux1f+wo-cjnkhqgjc2hzho4...@mail.gmail.com