Coverity has to reset their database soon to recover from a database problem (the one that's keeping new scans from showing up).
Somebody should probably scrape the Wine results from the Coverity database soon so we can avoid losing any annotations we care about... - Dan
On Thu, 2006-10-05 at 16:02 -0700, Dan Kegel wrote:
Coverity has to reset their database soon to recover from a database problem (the one that's keeping new scans from showing up).
Somebody should probably scrape the Wine results from the Coverity database soon so we can avoid losing any annotations we care about...
- Dan
Hi,
the email sent by Coverity also asks for a 'main contact'. Do we have such a person already?
Can we give them a date when they could recreate the database?
Maybe it's good to have a clean start on this. I've found several 'annotations' that just say 'BUG' back in April and nothing else. We should come up with some sort of standard for this, or am I talking rubbish now?
Cheers,
Paul.
On 10/5/06, Paul Vriens Paul.Vriens@xs4all.nl wrote:
the email sent by Coverity also asks for a 'main contact'. Do we have such a person already?
Not that I know. Are you volunteering?
Can we give them a date when they could recreate the database?
Maybe it's good to have a clean start on this. I've found several 'annotations' that just say 'BUG' back in April and nothing else. We should come up with some sort of standard for this, or am I talking rubbish now?
I'm ashamed to say I haven't looked. If you have, and the annotations don't look worth keeping, then let's just start over. So how about this: let's tell them tomorrow morning that it's ok to wipe the database on Tuesday. That should give anyone interested time to look at the annotations and make sure they agree. - Dan
On Thu, 2006-10-05 at 23:55 -0700, Dan Kegel wrote:
On 10/5/06, Paul Vriens Paul.Vriens@xs4all.nl wrote:
the email sent by Coverity also asks for a 'main contact'. Do we have such a person already?
Not that I know. Are you volunteering?
If nobody steps up, sure.
Can we give them a date when they could recreate the database?
Maybe it's good to have a clean start on this. I've found several 'annotations' that just say 'BUG' back in April and nothing else. We should come up with some sort of standard for this, or am I talking rubbish now?
I'm ashamed to say I haven't looked. If you have, and the annotations don't look worth keeping, then let's just start over. So how about this: let's tell them tomorrow morning that it's ok to wipe the database on Tuesday. That should give anyone interested time to look at the annotations and make sure they agree.
- Dan
That's fine with me. I haven't looked through all annotations, so there could be something worthwhile to keep.
On the other hand, several annotations are from April (6 months development since) and several bugs have been fixed already (but of course not seen).
What about the fact, that we need some rules/standards for ourselves to deal with these Coverity reports?
For example, if something is marked as a BUG then I'd expect the person that marked it, to follow up (either by a patch, by chasing somebody to look into this, or to create a bugzilla entry). He/she has spent already some time looking into this so why waste that time.
As soon as the number of defects drops down to a manageable number, the chasing could even be done by the 'main contact' :-).
Cheers,
Paul.
On 10/6/06, Paul Vriens Paul.Vriens@xs4all.nl wrote:
On the other hand, several annotations are from April (6 months development since) and several bugs have been fixed already (but of course not seen).
Say, has anybody posted a summary of the Coverity reports lately? e.g. how many issues it flagged in Wine, and how many have been examined?
What about the fact, that we need some rules/standards for ourselves to deal with these Coverity reports?
A page at the winehq wiki might go a long way, hint hint :-) - Dan
On Fri, 2006-10-06 at 00:35 -0700, Dan Kegel wrote:
On 10/6/06, Paul Vriens Paul.Vriens@xs4all.nl wrote:
On the other hand, several annotations are from April (6 months development since) and several bugs have been fixed already (but of course not seen).
Say, has anybody posted a summary of the Coverity reports lately? e.g. how many issues it flagged in Wine, and how many have been examined?
http://scan.coverity.com/ is the only place I know of.
What about the fact, that we need some rules/standards for ourselves to deal with these Coverity reports?
A page at the winehq wiki might go a long way, hint hint :-)
- Dan
I do have a day-job :-).
Cheers,
Paul.
On 10/6/06, Paul Vriens Paul.Vriens@xs4all.nl wrote:
Say, has anybody posted a summary of the Coverity reports lately? e.g. how many issues it flagged in Wine, and how many have been
examined?
http://scan.coverity.com/ is the only place I know of.
OK, I just logged in there and scraped the two main report pages for the last recorded run (July 21st), so we at least have some record of which files have which bugs flagged and how they were classified by wine developers, if at all (though my scrape doesn't have line numbers).
Here's the less-detailed of the two reports:
Name Uninspected Bug False Ignore Pending Resolved Total Everything 335 77 49 7 9 3 480 wine 335 77 49 7 9 3 480 wine/dlls 274 73 48 2 9 2 408 wine/dlls/advapi32 0 1 3 0 0 0 4 wine/dlls/advpack 0 1 1 0 0 0 2 wine/dlls/avifil32 0 1 0 0 0 0 1 wine/dlls/cabinet 2 5 0 0 0 0 7 wine/dlls/comctl32 10 1 1 0 2 0 14 wine/dlls/crypt32 1 5 1 0 0 0 7 wine/dlls/d3d9 6 0 0 0 0 0 6 wine/dlls/dbghelp 15 0 0 0 0 0 15 wine/dlls/devenum 0 1 0 0 0 0 1 wine/dlls/dinput 3 0 0 0 0 0 3 wine/dlls/dmime 7 0 0 0 0 0 7 wine/dlls/dmloader 5 0 0 0 0 0 5 wine/dlls/dmstyle 5 0 0 0 0 0 5 wine/dlls/dplay 3 0 0 0 0 0 3 wine/dlls/dplayx 3 0 0 0 0 0 3 wine/dlls/dsound 2 1 0 0 0 0 3 wine/dlls/gdi 6 1 1 1 0 0 9 wine/dlls/imagehlp 1 0 0 0 0 0 1 wine/dlls/itss 2 0 0 0 0 0 2 wine/dlls/kernel 27 6 4 0 0 1 38 wine/dlls/mapi32 0 0 4 0 0 0 4 wine/dlls/mciavi32 2 0 0 0 0 0 2 wine/dlls/mlang 2 0 0 0 0 0 2 wine/dlls/mpr 0 2 0 0 0 0 2 wine/dlls/msacm 4 2 0 0 0 0 6 wine/dlls/msi 4 1 3 0 0 0 8 wine/dlls/msrle32 1 0 0 0 0 0 1 wine/dlls/msvcrt 0 4 17 0 0 0 21 wine/dlls/msvfw32 0 1 0 0 0 0 1 wine/dlls/msxml3 3 0 0 0 0 0 3 wine/dlls/netapi32 0 1 0 0 0 0 1 wine/dlls/ntdll 4 7 2 0 0 1 14 wine/dlls/ole32 5 2 1 1 0 0 9 wine/dlls/oleaut32 14 2 1 0 0 0 17 wine/dlls/opengl32 10 0 0 0 0 0 10 wine/dlls/qcap 3 0 0 0 0 0 3 wine/dlls/quartz 8 0 0 0 0 0 8 wine/dlls/riched20 1 6 0 0 4 0 11 wine/dlls/rpcrt4 6 2 0 0 0 0 8 wine/dlls/rsaenh 2 0 0 0 0 0 2 wine/dlls/secur32 0 0 1 0 0 0 1 wine/dlls/serialui 1 0 0 0 0 0 1 wine/dlls/setupapi 1 3 0 0 0 0 4 wine/dlls/shell32 12 2 2 0 1 0 17 wine/dlls/shlwapi 1 3 0 0 0 0 4 wine/dlls/url 1 1 0 0 0 0 2 wine/dlls/urlmon 1 0 0 0 0 0 1 wine/dlls/user 33 1 1 0 1 0 36 wine/dlls/uxtheme 2 2 0 0 0 0 4 wine/dlls/version 0 0 1 0 0 0 1 wine/dlls/wined3d 17 0 0 0 0 0 17 wine/dlls/winedos 1 0 0 0 0 0 1 wine/dlls/wininet 13 2 1 0 0 0 16 wine/dlls/winmm 13 0 0 0 0 0 13 wine/dlls/winspool 0 0 1 0 1 0 2 wine/dlls/wldap32 0 0 2 0 0 0 2 wine/dlls/ws2_32 0 1 0 0 0 0 1 wine/programs 16 2 0 1 0 1 20 wine/programs/regedit 0 1 0 0 0 0 1 wine/programs/rpcss 1 0 0 0 0 0 1 wine/programs/taskmgr 1 0 0 0 0 1 2 wine/programs/wcmd 2 0 0 0 0 0 2 wine/programs/winecfg 2 0 0 1 0 0 3 wine/programs/wineconsole 1 0 0 0 0 0 1 wine/programs/winedbg 4 0 0 0 0 0 4 wine/programs/winemenubuilder 1 0 0 0 0 0 1 wine/programs/winetest 2 1 0 0 0 0 3 wine/programs/winhelp 2 0 0 0 0 0 2 wine/server 1 2 1 0 0 0 4 wine/tools 44 0 0 4 0 0 48 wine/tools/widl 6 0 0 0 0 0 6 wine/tools/winebuild 2 0 0 0 0 0 2 wine/tools/winedump 20 0 0 0 0 0 20 wine/tools/winegcc 7 0 0 4 0 0 11 wine/tools/wmc 3 0 0 0 0 0 3 wine/tools/wrc 5 0 0 0 0 0 5
On 10/6/06, Paul Vriens Paul.Vriens@xs4all.nl wrote:
For example, if something is marked as a BUG then I'd expect the person that marked it, to follow up (either by a patch, by chasing somebody to look into this, or to create a bugzilla entry). He/she has spent already some time looking into this so why waste that time.
Going through the report and marking issues as BUG or FALSE is one task in itself just like people help triage bugs in the bugzilla. We shouldn't expect anything more from them, though they're certainly encouraged to fix the bugs. We don't expect developers that triage bugs in bugzilla to fix every bug they mark as confirmed either.
-
Dan Kegel -
James Hawkins -
Paul Vriens