Adding an <info> tag?

[David Malcolm]

On Tue, 2013-02-12 at 13:45 -0500, Paul Tagliamonte wrote:
> On Tue, Feb 12, 2013 at 01:43:00PM -0500, David Malcolm wrote:
> > Currently we have two kinds of result within an <analysis>:
> >   * <issue> elements, representing a warning from an analysis code about
> > a possible problem with the software-under-test (SUT)
> >   * <failure> elements, representing a report about a failure of an
> > analysis tool to achieve full coverage of the SUT (e.g. the tool crashed
> > or timed out)
> > 
> > I'm thinking it might be useful to be able for an analyzer to record
> > arbitrary extra information about the software-under-test, where it
> > isn't an issue as such, but for custom data-gathering about the SUT, so
> > I'm considering adding an <info> element as a third type of result, with
> > an optional <location> and allowing storing <custom-fields>.
> > 
> > The motivating use-case for me is in my mass-analysis of Python
> > extension modules: I though it might be interesting to gather some stats
> > on uses of the CPython API, and it's not a bit stretch to add this to
> > cpychecker's firehose output.   Perhaps one could use this to build an
> > lxr-style indexing tool also.
> > 
> > Thoughts?
> 
> Massively +1. I've been protyping some code that results in this sort of
> data (I'm interested in copyright data -- it's not an "issue" to have
> code under the GPL, or BSD-3, or Expat) and was thinking of filing
> issues with severity "information" for those types of things.
> 
> I was pondering sending in a request, but you beat me to it.
> 
> Totally +1

I've committed an attempt at this idea as:
https://github.com/fedora-static-analysis/firehose/commit/0fda32b3086ba1985e3afc8f5f8929ce9386f60e