Frédéric Delanoy wrote: -Application works flawlessly with some DLL overrides, other settings or third party software. +Application works flawlessly with some DLL overrides, some patches applied, other settings or third party software.
Really? IMHO they should still be silver. Patches are very hard for the average user to deploy without a third party front end like POL, and appdb is not about POL. - Dan
On Wed, 16 May 2012 13:16:11 -0700 Dan Kegel dank@kegel.com wrote:
Really? IMHO they should still be silver. Patches are very hard for the average user to deploy without a third party front end like POL, and appdb is not about POL.
AppDB test reports are supposed to reflect the performance of the Wine release tested. Strictly speaking, we shouldn't allow any workarounds at all, but we'd have to throw out most of the accumulated data if we made that change. IMO, a reasonable compromise draws the line at what an ordinary, non-technical user can reasonably be expected to know how to do. Copying files, even whole directories, is something everyone can be expected to know. Patching and compiling Wine isn't.
On Wed, May 16, 2012 at 3:48 PM, Rosanne DiMesio dimesio@earthlink.net wrote:
On Wed, 16 May 2012 13:16:11 -0700 Dan Kegel dank@kegel.com wrote:
Really? IMHO they should still be silver. Patches are very hard for the average user to deploy without a third party front end like POL, and appdb is not about POL.
AppDB test reports are supposed to reflect the performance of the Wine release tested. Strictly speaking, we shouldn't allow any workarounds at all, but we'd have to throw out most of the accumulated data if we made that change. IMO, a reasonable compromise draws the line at what an ordinary, non-technical user can reasonably be expected to know how to do. Copying files, even whole directories, is something everyone can be expected to know. Patching and compiling Wine isn't.
-- Rosanne DiMesio dimesio@earthlink.net
Some of the more popular patches are available in PPA's, and I'd be willing to bet that many of the less tech savvy users are running Ubuntu and can figure out how to add a PPA.
On Wed, 16 May 2012 15:55:37 -0500 Austin English austinenglish@gmail.com wrote:
Some of the more popular patches are available in PPA's, and I'd be willing to bet that many of the less tech savvy users are running Ubuntu and can figure out how to add a PPA.
They're also available through PlayOnLinux. Do you want to open the AppDB to test reports using POL? If no, what is the rationale for keeping them out if test reports for patched versions are allowed? If yes, what about all the other third party apps out there?
BTW, I'm not necessarily arguing against this. I'm more concerned with practicalities than philosophy, and it would make my job easier if POL et. al. could simply be treated as distros (WineSkin users already keep trying to add it as a distro). But does anyone really want to go down that road?
On Wed, May 16, 2012 at 10:48 PM, Rosanne DiMesio dimesio@earthlink.net wrote:
On Wed, 16 May 2012 13:16:11 -0700 Dan Kegel dank@kegel.com wrote:
Really? IMHO they should still be silver. Patches are very hard for the average user to deploy without a third party front end like POL, and appdb is not about POL.
AppDB test reports are supposed to reflect the performance of the Wine release tested. Strictly speaking, we shouldn't allow any workarounds at all, but we'd have to throw out most of the accumulated data if we made that change. IMO, a reasonable compromise draws the line at what an ordinary, non-technical user can reasonably be expected to know how to do. Copying files, even whole directories, is something everyone can be expected to know. Patching and compiling Wine isn't.
In my understanding, Gold is about an application working flawlessly if some workaround/setting is used. IMHO a patched wine can be seen as a workaround, albeit harder to apply. If the patch(es) is(are) sufficiently popular, somebody may create a PPA for less savvy users.
If this patch isn't accepted, I wonder why some entries like those for Diablo III were accepted, since some indicate you need to apply some patches. e.g. http://appdb.winehq.org/objectManager.php?sClass=version&iId=25953&i...
Also, if patched wine isn't accepted in AppDb ratings, the app entry would likely be marked as Garbage, and most people won't bother to read the specific entries, while a workaround (patches) can be used. Reading AppDB HOWTO entries seems counterintuitive for Garbage-rated apps, IMHO
Frédéric
On Thu, 17 May 2012 09:56:17 +0200 Frédéric Delanoy frederic.delanoy@gmail.com wrote:
If this patch isn't accepted, I wonder why some entries like those for Diablo III were accepted, since some indicate you need to apply some patches. e.g. http://appdb.winehq.org/objectManager.php?sClass=version&iId=25953&i... th=71519
They shouldn't have been accepted. There are lots of things in the AppDB that shouldn't be there.
Also, if patched wine isn't accepted in AppDb ratings, the app entry would likely be marked as Garbage, and most people won't bother to read the specific entries, while a workaround (patches) can be used. Reading AppDB HOWTO entries seems counterintuitive for Garbage-rated apps, IMHO
People don't read the entries as it is, whatever the rating. I frequently have to point things out to users on the forum that are clearly stated in the AppDB entry that they claim to have read. And the rating system itself is deeply flawed: ratings depend as much on the user's skills and tolerance for problems as they do on the actual performance. If it were up to me, we'd get rid of individual ratings, and just let users report the facts.
I agree that what is most useful in the AppDB is the specific information on how to make an app work, and yes, patches do fall into that category. Them problem with accepting them is that then there is no valid reason for rejecting reports that use POL, WineSkin, etc. I'll repeat the question I asked Austin: is that the road you all want to go down? Because I could easily start accepting them right now, without any need for changes to the AppDB code.
I think the test results should be only from vanilla wine. While the additional information which can be provided, should be used to inform about patches and their affection to the particular application with wine.
This is unless the appdb will allow us to filter out test results that were either done with patched wine, or some unsupported variant like POL or such.
http://appdb.winehq.org/objectManager.php?sClass=version&iId=24699&i... The above example shows only the results from, unpatched wine. While the howto section informs about patch that can potentially solve all issues, but isn't the prober way to solve the problem.
On Thu, 17 May 2012 16:05:35 +0300 Jari Vetoniemi mailroxas@gmail.com wrote:
http://appdb.winehq.org/objectManager.php?sClass=version&iId=24699&i... The above example shows only the results from, unpatched wine. While the howto section informs about patch that can potentially solve all issues, but isn't the prober way to solve the problem.
IMO, that's the best way to handle it under the current system.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
17.05.2012 17:05, Jari Vetoniemi wrote:
This is unless the appdb will allow us to filter out test results that were either done with patched wine, or some unsupported variant like POL or such.
That's is exactly the same vision as mine: AppDB is about unpatched Wine, sure, but from end-user PoV patches are as valid workarounds as anything else. Still, patches are relatively hard to install and use, so AppDB should distinguish test results submitted for patched Wine from test results submitted for unpatched Wine and allow end-users to filter out what they want. If it would be that way - every user would easily find the results that apply to his Wine usage case. One don't want to use anything other than "almost vanilla" Wine supplied with his/her distro? NP, filter out results for unpatched Wine. One feels comfortable with patching and compiling Wine (or installing packages from untrusted third-party PPA/repos)? OK, here are the results for patched versions. And so on.
IMHO it'd be better that the current situation when I as a app maintainer have to deal with co-maintainers accepting restults that shouldn't be accepted at a first place (and simply deleting results without the ability to mark them back as a "Rejected - please, improve and resubmit" is a bit... em... rude), and with flood of incorrect test results from users who use patched Wine and pretty sure that it's OK to post results for it having ratings like "Platinum" or "Gold". Yesterday I spent half or a day rejecting the results for Diablo III and sending PMs to result posters describing why it wasn't possible to accept results from them. Most replies I've got were people complaining about AppDB not giving them a possibility to mark their results as being for patched Wine or questions about "then why had the test result X for app Y was accepted?".
- -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
IMO, AppDB should gather enough information form the user to assign the rating automatically. For example, answering "no" for "Installs?" should automatically lower the rating. "Runs?" might be a bit too is a bit too ambiguous. More over, the ratings should not be something you have to click on a help page to figure out what they mean.
We should have a "Rating" section that asks a series of questions. Application starts with 5 points and looses them:
--- Rating --- Installs? ( ) Yes ( ) No {-4}
How well does the application work? ( ) Perfectly. The application preforms the same as it would on Windows. ( ) Good. There are some minor functionality, visual appearance, or performance issues {-1} ( ) Unusable. Crashes or is otherwise useless for the application's intended purpose {-4}
Does the application require workarounds (see below) for the above level of functionality? ( ) No ( ) Yes, but only for minor functionality {-1} ( ) Yes, for major functionality {-2}
What kinds of workaround are needed? Select all that apply: {These are grayed out unless the user selects a "workaround" option above. They need not effect the rating but serves to help the tester answer the question above "right" answer for the above question. Additionally it's nice information to have for users who read the review.} [ ] Manual configuration such as editing registry settings, configuration files, starting application with special parameters, etc. [ ] Manual file copy from other Windows installs or installation media [ ] Installation of Windows native components (dll overrides, winetricks, etc) [ ] Patched Wine [ ] Persistence. Wine frequently crashes due to some intermittent failure but eventually if you keep trying you get what you need. [ ] Other (Explanation provided in other text fields)
How difficult is it to use the workaround(s)? ( ) Trivial. Anyone reading this review should be able to implement them without difficulty even if they are inexperienced. ( ) Intermediate. Requires some complex steps or third party software (e.g. winetricks) {-1} ( ) Difficult. Requires building Wine from source or in-depth knowledge. {-3} ------
With the current system, rating is open to ambiguity and misuse. Users often use it as an indicator of how much they like the application or how excited they are that it works with Wine. If we generate the rating for them, then they have to lie (game the system) to get a higher rating than what is deserved.
Of course this would require a bunch of work from someone and it may be more invasive than desired. Just my imaginative 2c at this point.
On Fri, 18 May 2012 14:52:28 -0600 James Eder jimportal@gmail.com wrote:
With the current system, rating is open to ambiguity and misuse. Users often use it as an indicator of how much they like the application or how excited they are that it works with Wine.
Yes.
If we generate the rating for them, then they have to lie (game the system) to get a higher rating than what is deserved.
Some will do that. Some already try to sneak inflated ratings in by mentioning problems in the Extra comments section rather than the "What doesn't work" section.
Of course this would require a bunch of work from someone
Which is why it's unlikely anything will ever change, even if everyone loves the idea.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
17.05.2012 11:56, Frédéric Delanoy wrote:
If this patch isn't accepted, I wonder why some entries like those for Diablo III were accepted, since some indicate you need to apply some patches. e.g. http://appdb.winehq.org/objectManager.php?sClass=version&iId=25953&i...
They were accepted because it is (a) known that the game itself works without need to patch Wine, it is installed/launcher who require it and (b) I had specifically quired each reporter to test with vanilla Wine the game itself to check if it's working and only then accepted the test results. You could read some info about that downwards in the comments section of AppDB D3 page.
- -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
17.05.2012 00:16, Dan Kegel wrote:
Frédéric Delanoy wrote: -Application works flawlessly with some DLL overrides, other settings or third party software. +Application works flawlessly with some DLL overrides, some patches applied, other settings or third party software.
Really? IMHO they should still be silver. Patches are very hard for the average user to deploy without a third party front end like POL, and appdb is not about POL. - Dan
I thinks that using silver won't be correct here either. "Some patches" could be treated too widely - and I think that we really don't want someone to use patch that, say, changes most of the wineserver to be inproc, and then treat it as "some patches" and rate an app as "Golden" with it. And an argument that patching Wine isn't something that is easy for average user is also a valid point.
IMO if we want to handle "patched Wine" case in AppDB is some sane manner it would be better just to add a separate flag for a testreport to indicate was the Wine used for testing "vanilla" or not - it would make more sense for users and would allow to display test results acquired with a patched Wine in a visually distinguishable way from reports acquired with vanilla Wine. Thus, non-experienced users would be mostly checking results and ratings poster for non-patched Wine, while geeks would be doing their geekish business that they had always been doing.
Just two my cents.
- -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
On Wed, May 16, 2012 at 1:50 PM, Alexey Loukianov mooroon2@mail.ru wrote:
Really? IMHO they should still be silver. Patches are very hard for the average user to deploy without a third party front end like POL, and appdb is not about POL. - Dan
I thinks that using silver won't be correct here either.
Yes, sorry, after I posted that, I realized that patches should force it down to bronze or lower. http://appdb.winehq.org//help/?sTopic=maintainer_ratings doesn't even allow patches at all at the moment.
"Some patches" could be treated too widely - and I think that we really don't want someone to use patch that, say, changes most of the wineserver to be inproc, and then treat it as "some patches" and rate an app as "Golden" with it. And an argument that patching Wine isn't something that is easy for average user is also a valid point.
IMO if we want to handle "patched Wine" case in AppDB is some sane manner it would be better just to add a separate flag for a testreport to indicate was the Wine used for testing "vanilla" or not - it would make more sense for users and would allow to display test results acquired with a patched Wine in a visually distinguishable way from reports acquired with vanilla Wine. Thus, non-experienced users would be mostly checking results and ratings poster for non-patched Wine, while geeks would be doing their geekish business that they had always been doing.
A "runs well with patched wine" checkbox might be useful, but would be very confusing. Maybe if it forced the rating to be garbage that would be ok.
-
Alexey Loukianov -
Austin English -
Dan Kegel -
Frédéric Delanoy -
James Eder -
Jari Vetoniemi -
Rosanne DiMesio