Article on wine development strategy
scott at open-vote.org
Sat Apr 18 06:11:43 CDT 2009
Reece Dunn wrote:
> 2009/4/18 Kai Blin <kai.blin at gmail.com>:
>> On Saturday 18 April 2009 05:21:20 Dan Kegel wrote:
>>> The one that worked out best was to pick some random
>>> user who's almost happy, fix the last few bugs that
>>> are keeping his apps from working, and then once
>>> he's happy, move on to the next such user.
>> The problem seems to be identifying these people. The model assumes that you
>> can tell which piece of software almost works, and that you know the almost
>> happy users. In reality, you only seem to hear from the pretty unhappy users
>> and the occasional really happy user. Susan Cragin is about the only user I
>> can think of off the top of my head who's almost happy and could be made
>> completely happy by fixing all of the remaining bugs in DNS.
> You could also pick some games as well. A lot of the Oberon Media
> casual games work (probably around 50-60%), but there are bugs in the
> launch page that means you don't get a seamless experience. The Game
> Socks versions of the games have a seamless experience with the splash
> loader (not sure about purchasing games there, though).
> Other popular games and games platforms like WoW and Steam will also
> help your gamer users.
The one trouble with gamer users is that they tend to have a lot of
games that they want working. Probably the major exception is WoW --
and it's a very wise choice for us to make sure it works really well,
since many users want that and only that.
> CodeWeavers are doing this to some extent - now branching out to fix
> other applications. There was a big push a while back to get Photoshop
> AppDB or something similar is useful for determining the most popular
> applications that people are using. This does not cover the users,
> though -- a user may be happy with one app, but unhappy with another
> because that one is obscure/unpopular (think in-house applications).
>> Also, reality has us deal with the fact that new applications are added while
>> we're working on the old ones, and looking at the graphs, we're only going to
>> make a significant number of users happy when we're about 98% done fixing the
>> bugs. I realize that it's a bit hard to model "rate of new applications with
>> new bugs being added", but that's what happens in real life.
> Not just new applications, but upgrades as well. iTunes is a
> constantly shifting landmark, from what I understand. IE6, 7 and 8 use
> more of the Windows API. Photoshop only works with earlier versions.
> There have been updates to fix Office 2007 SP1 issues.
> Some of the major pain points I can see in the future for getting Wine
> to run applications are:
> 1. applications that use the newer Windows Vista and 7 APIs -- this
> is ok if the application is also designed to run on XP or earlier, but
> applications will start targetting XP and later or Vista and later.
> 2. applications that use .NET, WinForms and/or WPF -- these should
> be ok on Wine if the Microsoft and/or Mono runtimes can support these.
> 3. applications that start using more (unimplemented or partially
> implemented) of the XP and earlier APIs.
> So a happy user today could be an unhappy user tomorrow if they try
> and upgrade one of their applications. But such is the nature of
> playing continual catchup.
Perhaps this implies we shouldn't try so hard to get the apps that are
about to break on upgrade, even if they are big ones. We've spent a lot
of effort chasing Photoshop, but if only the Photoshop of three years
ago works then we haven't really gained much directly.
More information about the wine-devel