2008/12/17 Austin English austinenglish@gmail.com:
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.
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.
Any logs like this would only be useful if they were automatically processed. For example, a list of top crashers could be produced, or something like the Kernel Oops report statistics.
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.
The use in statistics here would be to know what crashes are most frequent (via automated tools). If these could be given an id (e.g. a sha1 hash) they could be associated with a bug report to show which crashes (that have a bug report) are more active. This could help with retesting a bug and testing if a bug is still active in the latest version of wine.
Taking a step back... there was a patch a few days ago to add a winewatson application similar to the drwatson program in Windows. This is a better way to go (at least initially) as it serves several purposes: 1. it shows people running wine applications directly instead of going via a command shell that something went wrong; 2. it allows wine to gather information such as terminal output and stack trace that the user can copy and paste in a bug report; 3. it allows the user to be pointed at the wine bugzilla page to report a bug if one does not already exist (including the terminal outbut and stack trace captured by winewatson), or confirm that the bug is still valid.
I think that this is all that is necessary and should satisfy the needs outlined here without being a burden to developers and fitting into the current way that bugs are triaged and processed. It should also help the more novice users create better bug reports.
- Reece