GSoC 2009 Proposal - AppDB Assistant

[Ben Klein]

2009/3/22 Illya Klymov <illya.klymov at gmail.com>:
> So, let's imagine we have a software which I call "AppDB Assistant" with
> following functionality:

There has been quite some activity on wine-devel recently regarding
the AppDB, including a few ideas on how to automate uploading
information or configuring Wine based on AppDB entries.

> 1) an ability to quickly submit a report about application to AppDB. A lot
> of data (Wine version, Linux distribution, wine settings) could be obtained
> automatically. An application information with high probability could be
> fetched from meta data, stored in EXE file. In general, i see that like
> after closing an app I see additional screen "Please take a couple of
> seconds and send feedback about your experience with $SOFTWARE_NAME to
> AppDB", and buttons "Platinum","Gold", etc. Of course this should be
> configured via winecfg (if user do not want to obtain such data)

Grabbing the version number of the application from the EXE metadata
could prove to be unreliable. A lot of Windows apps don't include
metadata, or include unusual values in the metadata. Then again, a lot
of apps don't make it easy to see what the version you're using is in
any other way, and as a result there are a lot of "1.0" versions on
AppDB that map to "initial retail version".

One example is Theme Hospital, which as the original retail version
was released as "Beta 4", and Bullfrog provided a patch that upgraded
to "Beta 5". The only hint of version numbers is provided by the patch
itself, and as a result some user wanted to submit a "1.0" version to
indicate the original retail release. As I was a supermaintainer of
Theme Hospital and already had the "Beta 4" version, I removed the 1.0
version and engaged in a lengthy email discussion over whether the
retail release was "Beta 4" or "1.0".

> 2) an ability to generate a "configuration guide" - in this mode an "expert
> user" selects important data to be included into a guide (for example that
> app runs _only_ under Windows XP emulation, an important registry values
> etc.). As a result a special file, describing an app-specific configuration
> of wine is uploaded to appdb
> 3) an ability to "preconfigure Wine". That means that based on
> "configuration guide" created on step 2 "AppDB Assistant" can configure wine
> in one click. If any additional dlls are required a warning message is
> displayed with possible information where to obtain them.

There has been discussion about "preconfiguring" Wine with AppDB data,
and the general consensus is that it's a bad idea. We run the risk of
becoming like wine-doors, playonlinux, and other tools we don't
support at WineHQ. The biggest problem is that there is no way to
determine if any particular configuration will still work when a new
version of Wine or a new version of the app is installed. There are
also cases where installing a workaround/native DLL for one app will
cause a whole lot of others to break.

> I see the following benefits on such software:
> 1) increasing appdb actuality - with a way more data from users we can
> provide more accurate info;
> 2) simplified regression testing - for example if user downloaded a
> "configuration guide" and it didn't work with newer wine - this is a
> possible regression (decreased chance of human error)

Regression testing is *only* useful if there are no native DLL
overrides configured. Test data submitted using a set of
pre-configured overrides is nowhere near ideal for Wine.