On 01/05/2010 03:44 AM, Jeremy White wrote:
The Top Ten Single Charts
This are the messages with the most occurrences in a single file.
Nifty!
Well, I'm not that proud of that table: Interestingly seven out of the top ten FIXMEs in a single file have been seen *only* in that one file. While proper fixes that remove the FIXMEs are always good I'm not so sure about just silencing those. Probably a better table would be
The Noisiest FIXMEs that show up at least in 1% of the collected reports: Lines | Files | Channel:Text ------+-------+------------- 2203 | 44 | d3d9:Direct3DShaderValidatorCreate9 stub 2040 | 36 | ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000109 1492 | 34 | mshtml:nsChannel_GetSecurityInfo default action not implemented 1450 | 30 | d3d:debug_d3dformat Unrecognized 909201952 (as fourcc: R16) WINED3DFORMAT! 1449 | 30 | d3d:debug_d3dformat Unrecognized 909200449 (as fourcc: AL16) WINED3DFORMAT! 1446 | 30 | d3d:getFormatDescEntry Can't find format unrecognized(909200449) in the format lookup table 1446 | 30 | d3d:getFormatDescEntry Can't find format unrecognized(909201952) in the format lookup table 1002 | 81 | wininet:InternetLockRequestFile STUB 877 | 209 | shell:DllCanUnloadNow stub 734 | 31 | msi:ACTION_CustomAction Rollback only action... rollbacks not supported yet
How hard would it be to add some git-blame fu to that,
Hard. You'll need to generate a regexp from the the message text and git grep with that. Of course a previous git grep on the debug channel will help to reduce the search space.
and then we'd know who to blame<evil grin>?
No, you don't. You know who last edited the respective line. But even if you get the guy who added the FIXME/ERR you'd end up blaming the wrong person. It isn't like people would add those FIXME/ERR in the inner loops of a function. Most likely it is an other part that triggers the FIXME/ERR; it might even be application code that does "stupid" things.
And winefixme is not about blame but about helping to figure out what FIXME/ERR messages are common and thus worth fixing or at least to tame a little the noisiest ones (we really could make good use of FIXME_ONCE/ERR_ONCE macros).
bye michael