2008/12/18 Ben Klein shacklein@gmail.com:
2008/12/18 Sander Devrieze s.devrieze@linux.be:
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.
Is it a goal for Wine to be included as standard in distros? I'd say not. The correct solution is *nix-native applications. E.g., how many people use utorrent in Wine when they could use Deluge or Transmission? Sure, Wine's goal should include support for apps like utorrent (in that Wine's goal is to run as many Windows apps as possible), but they shouldn't be prefered over *nix-native apps.
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.
Known by whom? Are you suggesting appdb scraping?
No, I was thinking about including a list of hashes for the applications that are officially supported in the Wine distribution.
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.
Sounds elaborate to me :) Though the winewatson sounds like it could handle this sort of thing.
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.
From what I've seen, most bugs in Wine aren't detectable by software - it THINKS it's working fine, but the user can tell it's not :) In any case, this would require a potentially large database of known bugs and their symptoms ...
I meant that this database can be used to see if a *manually* reported bug may also affect other applications. So, developers and testers can get a list of software that can be used to see if the bug is fixed.
reports from stable or nonlatest versions would be largely ignored, and users of the latest beta can be asked to contribute in other ways, such as on the download page itself.
Remember, it doesn't take much work for us to know that an application doesn't work - a single bug report can do that. Once we have that, we don't need to ask a million other users (literally) for confirmation.
Only geeks file good bug reports. Normal people don't care and will not spend energy on this.
There's been a lot of talk recently about targeting Wine towards end-users, e.g. the redesign of the website. It sounds like a great idea, but Wine is still very much a developer's tool. It's not user-friendly, and it won't be for a very long time, if ever.
Most end-users primarily don't report bugs because they don't want to spend time on this.
winewatson sounds like a developer's debugging tool, but it could prove useful for improving bad bug reports.
Note that Microsoft has a system where any old application crash can send a bug report to Microsoft. It's basically spamming yourself :)
-
Sander Devrieze