AppDB: Rating / Patching

[Ben Klein]

2009/1/20  <Joerg-Cyril.Hoehle at t-systems.com>:
> Hi,
>
> here are, from an obvious user perspective, my 0.02$ on the issue.
>
> - Platinum: app works "out of the box" -- without changing any
>  settings -- *and* as well as on MS-Windows. That means no feature is
>  missing: music plays, graphics look similar on both plattforms, the
>  perceived speed or responsiveness is similar, ...
> (Question: does the need to install thrid party SW like codecs or
> Quicktime preclude "platinum" because it's not "out of the box"?)

3rd-party software like codecs or Quicktime do not ship as part of
Windows, they ship as part of the software that depends on them. I
cover this again further down.

> For anything below platinum, I don't want AppDB to ask users to
> compare with MS-Windows. Users either don't care about MS-Windows or
> don't have the time to perform a dual installation or don't even have
> a MS-Windows machine!

This appears to defeat your argument, since the appdb is maintained
and updated by users. If users "don't care about" or "don't have the
time" for Windows, then you'll end up never getting a platinum rating
with this qualification.

> Yet to gain platinum rating, I concede that the additional effort to
> test the application's behaviour on MS-Windows is valuable to detect
> discrepancies between the two ("hey, I didn't know before that the
> application would play background music!").

Yes, it is valuable, however it's not practical, as you pointed out
earlier. It's also implying that you need a copy of Windows to use
Wine to its fullest. We shouldn't assume that *anyone* using Wine has
a copy of Windows too.

> - Garbage: nobody knows how to make this app work with that version of
>  wine.  Don't buy it, you are likely wasting your time & money.

Wine does not only run commercial applications. Instructing users to
not buy products in the rating definitions is, again, assuming far too
much about what the users are trying to do.

In some cases, there are apps that are impossible to make functional
in Wine. Your suggested description implies that there are no such
cases, and that some future version of Wine will be able to handle it.

> Anything else gets a rating above garbage, no matter how ugly the fix
> or patch is.  What counts is that there's a known way to make it work.
>
> - Bronze: the application shows a "promise" that some additional fixes
>  and patches may make it work well.

Wow, this is completely unsuitable as a rating description without a
detailed definition of what a "promise" means. It also disqualifies
cases of "it runs, but not well" where no known patches or "fixes"
make it run better.

> I'm opposed to the idea that a given AppDB version should only
> denote an unpatched wine in test results.  Consider how Dan Kegel
> recently recommended distributors not to distribute 1.1.12.  E.g. a
> hypothetical future Ubuntu package "1.1.12" may contain the official
> 1.1.12 plus the three patches that Dan Kegel recommends.

I thought you just said Dan was recommending distributors NOT distribute 1.1.12!

Also note that WineHQ distributes its own packages of Wine for Ubuntu.
Technically, we should only support these packages, and not those
shipped by Ubuntu.

> Users would likely not know nor notice.

This is the problem. If a user doesn't know what patches have been
applied to their Wine that make their application work, then the AppDB
will have blatantly incorrect information. AppDB implies that *no
patches* were applied to Wine when the apps were tested. Saying we
only want test data from unpatched Wine releases makes the implication
explicit instead. This is a good thing.

>  Typically, distributors add whatever
> patches they feel right to the upstream releases.
> So it does not seem practical to have the need for a patch prevent
> ratings above garbage (or bronze), as some people suggested here.

It's more impractical to allow users to submit test data from patched
Wines. What happens if the patches aren't specified in the test data,
or if the patches are something the user has written but hasn't made
public?

> To me, 1.1.12 plus N patches (N "small") is still 1.1.12 as far as the
> AppDB is concerned. However N>0 might preclude platinum, as defined above (except for Ubuntu users).

You have to define what "small" is. Even then, it doesn't help,
because you could have one really big patch, or one really small (as
in one-line) patch that violently changes the behaviour of Wine.

To me, and I would guess to most Wine developers, 1.1.12 means 1.1.12
as accessible from upstream. So if you go to Wine's directory on
ibiblio.org and download a tarball, you get the exact source used to
compile that version of Wine.

Note that some common patches, like the CoD/3DMark patch, break more
apps than they fix. In your opinion, should there be any criteria on
what patches should be allowed in test data for appdb?

> Similarly, AppDB might prevent Gold or Silver ratings depending on
> qualitative aspects of the steps needed to make an app work:
>  - need for known distributable third party libraries (e.g. codecs, Quicktime)
>   (not provided with the application's installer)

This is already covered in the current "Gold" rating description. If
the application requires such 3rd-party libraries that are *not
normally present* on Windows (e.g. codecs, Quicktime), then it should
ship with them. If the shipped 3rd-party libraries do not install for
whatever reason, it's not a Platinum app.

>  - complexity of settings (winecfg vs. *.reg vs. environment variable vs. ...)

Current "Platinum" description mentions winecfg. If you have to change
settings in winecfg to make it work, then it's not "Platinum". E.g,
copy-protection that disables itself when it detects WinNT. In theory,
the copy-protection should work correctly (or, "as expected"),
regardless of what Windows version is reported by Wine.

>  - nocd or not copy-protected executables

Unless these are shipped by the developer (e.g. the no-CD patches to
Starcraft and Diablo II released by Blizzard), these are 3rd-party
software. They're also more dangerous than just codecs and Quicktime,
which you mention before.

>  - patch to source, requiring compilation of wine
> E.g. Recompilation would prevent Gold?

There is no case where this _should_ be true. In reality, recompiling
Wine from source could produce different results if the original was
patched, or if some dependant libs (e.g. OpenGL, a common omission for
new users) are missing at configure stage, or if some incorrect or
incompatible CFLAG has been used.

> Would you agree that any application in need of a nocd would
> necessarily rate one level below another one not "equipped" with copy
> protection?

This is essentially what's covered in the current "Gold" description.
If it runs perfectly, but only with a no-CD patch, it's "Gold", not
"Platinum". However, if it runs like crap (i.e. "Bronze") but only
with a no-CD patch, I don't think "Garbage" would always be the most
suitable rating. It should be up to the user to decide just how badly
their app runs.

> Or does only the result count, and e.g. "Gold" is perfectly describing an
> application that works flawlessly "out of the box", except you need to
> replace the .exe with the nocd one between install and run? (So far I
> have handled it like this, a patch is not enough reason to drop a rating
> to garbage, this does not effectively describe the user experience.)

Again, this is not different from what the current rating descriptions say.

> Regards,
>        Jörg Höhle