Wineconf follow up: Wine Usage Data Collection

[Chris Ahrendt]

James Hawkins wrote:
> On Thu, Oct 9, 2008 at 2:09 PM, Chris Ahrendt <celticht32 at aol.com> wrote:
>> 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..
>>
> 
> How do you propose to 'improve problem determination or debugging'?
> 
> --
> James Hawkins
well you asked lol :
My wish list would be:

1) Some form of a Standard Gui Debugger GDB integration / eclipse etc..

2) A way to select  the debug flags used with an explanation of what
each is for... +seh is for this +relay does that...etc....

3) When you do +relay you could open separate output for each thread or 
send the +relay output for each thread to a different pipe so we can 
then pipe that information  to a file or open that pipe and use a tool 
to look at whats going on.

4) The ability to turn each of the +relay wine thread output on or 
off... Currently Wading through a relay log is a real pain and in some 
cases it prevents the problem from occuring. Time outs because of too 
much data being collected and then having to wade through and determine 
what to and not to turn off. A best practice somewhere showing the heavy 
hitters in a +relay log  and turn them off by default.  However, note
somewhere saying  if +relay doesn't give enough information then turn
on just these flags and run. That way we are not managing flag lists 
when trying to figure out whats going wrong in an application. IMHO 
+relay is too unweldly and turning each flag on individually is as well, 
so there needs to be some sort of happy medium somewhere.

5) A window or output  with a list of the important wine structures or 
resources that can be watched as the application runs with some 
explination of what those structures are for. And do the same with the 
dump. If the execution space is in an application output that fact. If 
we are in wine and we have the symbols of where we are then dump the 
code where we are too =)

6) Source code debugging in the GUI with step through, break points,
etc..( not like now in winedbg but more like one of the GUI's mentioned
before) and yes I know Gdb sort of works.. why not make it so it really 
works.. its not like I am asking to use VC++ to debug wine here lol.

7) Loading of application from gui debugger and then run it. This can be 
done with gdb now but its not the easiest in the world to do. This would 
be nice if it was made easier.

8) Ability to look at a stack and backtrace in the GUI or exception list 
and have the symbol associated with the backtrace placed in the 
execution trace.

9) Value Watches within the GUI.

10) Code Checking
        Some sort of bounds checking...
        Uninitialized variable checking....
        Unreachable Code Checking
        (I think is being done to an extent with Dan's runs of valgrind)

11) Use the GUI to help enforce the Wine Coding standard.. most modern
GUI environments let you specify a style of coding. This would help the 
new people understand and follow the coding standards set up... instead 
of guessing like they do now.

12) Online help / Context help...  point to the IC in the wiki... lots
of good stuff there... just hard to find sometimes....

13) Integration with bugzilla... they find a bug... they create it in
the GUI.. dump out the screen, stack and the like... so some of the base 
information is collected instead of wasting time back and forth and 
having so many invalid bugs. Again this format can be enforced through 
coding style templates... you want to submit a bug here is what you 
do... check boxes to include things... like I said screen shots... logs, 
traces, variables, hardware config, etc...

14) Integration with GIT... check and see if there is a new tree out
there.. if so... flag it and git it... (also update the GIT page with 
the latest instructions. Some of us are not GIT people by background...
CVS, etc.. so there is a really steep learning curve and its easy to 
mess a local GIT tree up and have to reload.

15) Link to whats fixed in the new GIT tree... or a list of it... 
something off the main WINEHQ page that says ok here is 1.1.15 here is 
what we fixed...

16) Link to Dan's patchwatcher status... (kinda a workflow sort of
thing) to know whats good and bad...

17) Generation of the GIT patch and then mail it to the list through a
button...

You have to remember alot of the new people coming in are not old
timers like some of us who grew up in a non-gui world.. Like it or not 
they are used to doing things in certain ways and I think we could get 
alot more people looking at bugs and helping fix them if we started 
thinking of something along these lines. This of course is not a 
complete list... But I think this might be a good next step for 
something like the summer of code people to do.. or whomever maintains 
the wine debugger to think seriously about. And no I am not criticizing 
wine in the least by the above. I really enjoy using wine and hacking 
around learning things. I want it to be the best it can be..


Chris