On Wed, Dec 17, 2008 at 2:10 PM, Sander Devrieze s.devrieze@linux.be wrote:
2008/12/17 Scott Ritchie scott@open-vote.org:
<snip> > If it's that users blame the distro when it's a Wine problem, then we > can present them with some sort of information before installing (or > perhaps running) Wine. After that we should get out of the way and let > them use Wine as normal.
Wine should go out of way when the Windows application is known to run very well under Wine or when the user submitted feedback for this application in the past. Also, the user easily can skip the dialog.
If the problem is that we're not getting enough feedback, then a default feedback nag might not be the best answer either.
Writing an elaborate system to tell us about known problems isn't particularly helpful;
It shouldn't be an elaborate system: it can be as easy as asking the user to click on a button to send a list of API calls, used DLLs, a hash of the .exe binary, some critical information of his system, amongst others to the Wine project. User based input in the feedback form may or may not be a good thing; I just gave this as an example; it is no necessary element in what I am proposing.
I guess this kind of feedback can be very powerful to Wine coders to create statistics like these:
- Most popular API calls
- Least popular API calls
- Most common API calls that make applications fail
- Unimplemented features used by very uncommon software (e.g.
custom-built applications within companies)
- Predicting the likelihood that a specific API call will be used when
another API call is used in an application
Maybe this information can be useful to detect which applications are affected by a bug in Wine. When this is known, testers can verify in multiple applications if the bug really is fixed in all applications.
It would take developer time and effort to analyze all these logs, and that time is better spent actually implementing those features and fixing bugs.
In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this.