Wineconf follow up: Wine Usage Data Collection

[Chris Ahrendt]

James Hawkins wrote:
> On Thu, Oct 9, 2008 at 9:32 AM, Chris Ahrendt <celticht32 at aol.com> wrote:
>> Alexandre Julliard wrote:
>>> "Henri Verbeet" <hverbeet at gmail.com> writes:
>>>
>>>> 2008/10/8 Austin English <austinenglish at gmail.com>:
>>>>> Currently, we've got two problems:
>>>>> 1) We want to collect Wine usage data, so we know where to concentrate
>>>>> our efforts.
>>>> Just curious, but do any actual developers really care about this? My
>>>> feeling is that bugzilla gives a pretty good idea of what people are
>>>> having trouble with already. (Not necessarily trying to shoot it down,
>>>> but keep in mind that receiving and processing the data will require
>>>> some infrastructure as well, and I wonder if it's worth all the
>>>> trouble.)
>>> I'm very skeptical too. I certainly don't think it's worth all the
>>> complexity that has been discussed around here, and in any case it can't
>>> be allowed to slow down the normal app startup code path.
>>>
>>> If there's really a need for this, it should be done somewhat like the
>>> Debian tracker, say by having a package that installs a cron job that
>>> looks for exe files and sends a list of the ones that have been accessed
>>> recently, or something along those lines.
>>>
>> Problem with that Alexandre is that alot of people get freaked out when
>> you start talking about doing that sort of thing. Several companies have
>> tried it and people had alot of problems with it.
>>
>> So this gets down to the base question what are we trying to accomplish
>> with this functionality that we are not getting now with the current
>> process? What can we change in the current process that would enhance
>> that to fill the short comings?  Does anything need to be changed?
>>
>> Personally, for what its worth, I think our time would be better spent
>> improving some form of error detection so that users would have an
>> easier time identifying where the issues might be. Automated dump
>> process and upload would be my thought. Then when the dump is recieved
>> it can be parsed with something along the lines of patchwatcher  to
>> determine the component that failed. If we want we could even have the
>> user opt in at that point to send the dump in or just trash it.
>>
>> Thoughts?
>>
> 
> We have a hard enough time determining which component is causing the
> bug as it is.  It would be near impossible to automate that detection.
> 
I am sure there are some things that may be automated somewhat... or we 
can compare exceptions etc... that way we can get some idea of atleast 
what the hot bugs are at the time...  Maybe one of the first tasks 
towards this is to improve problem determination... or debugging..

Chris