I've been working on my primary use-case for the gcc-python-plugin: finding bugs in C Python extension code. To that end, I've been attempting to automate a mass rebuild of all of the C Python extension code in Fedora, building it with the cpychecker code [1]. The source tree has recently grown a "misc/fedora" subdirectory, and within it there's a mass-rebuild.py script which attempts to rebuild a set of source packages (within chroots), injecting the gcc python plugin and the libcpychecker code into the build. It then slurps out all of the refcount-error.html files from the chroot into a results directory. On doing so, I'm running into the very real issue of what to do with all the errors that the plugin finds: some packages have dozens of errors. I want to provide something that an upstream maintainer of a python package can look at and understand, without subjecting them to a wall of noise. To that end, I've built a triaging script which walks over the results, and tries to triage them into high-severity through low-severity categories, and writes out an index.html indexing them all. You can see an example of all of this here, where the cpychecker code has analyzed the python bindings for GStreamer: http://people.fedoraproject.org/~dmalcolm/gcc-python-plugin/2012-02-10/gs... Thoughts? Hope this looks sane Dave [1] I'm tracking this for Fedora here: http://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts