Revisited: fedora-review

[Alec Leamas]

On 2013-08-28 16:42, David Malcolm wrote:
> On Wed, 2013-08-28 at 10:54 +0200, Alec Leamas wrote:
>> After digesting your remarks I have updated the xml produced by
>> fedora-review:
>>
>> - Adding source file info, but without sourceline/function etc. This
>> should make it possible for a UI to just display the spec file, which is
>> the proper action here.
>> - Adding a custom field for type of warning, similar to the
>> error/warning distinction used by many checkers.
>>
>> New example: http://ur1.ca/f9dua
> Thanks for posting this.
>
> I see that in the example XML above, each <issue> has a custom str-field
> "type", which seems to be one of MUST, SHOULD, or EXTRA.  The <issue>
> element has an optional "severity" attribute, perhaps this would be a
> better place to put this information?
>
> Looking at the thread that motivated the "severity" attribute:
> https://lists.fedoraproject.org/pipermail/firehose-devel/2013-February/000001.html
> it seems we added this for Debian's Lintian tool, so it would seem
> appropriate for fedora-review to use it.
Indeed. Is there any documentation on this besides the mailing list?

>> Questions:
>> - Is the general idea here that the if the UI just knows the name of the
>> source rpm, it knows how to retrieve  and unpack it, giving access to
>> the sources? Or? (BTW, how does this apply to debian?). In other words,
>> I kind of miss an overall usage scenario description.
> My plan when I started firehose was that I was going to be able to
> devote a chunk of $DAYJOB to build a UI/datastore, and run static
> analysis tools on all of Fedora's sources.
>
> I was going to use content-addressed store (rather like git's internal
> storage format) to efficiently store all files referenced by all reports
> within the issue db - hence the use of a crypto hash, so that one can
> simply store files by hash.
>
> However, in $DAYJOB I've been reassigned and am now working on gcc
> upstream (big internal cleanups targeting gcc 4.9, hopefully eventually
> building a static analyzer on top of GCC) - so I didn't get the time to
> build the firehose store.
>
> In the meantime, others from the Debian side of the Free Software house
> have built the UI/datastore - but AIUI, they're not storing the files in
> their datastore, instead pointing their UI at a different app which does
> store the files.

As i guessed, more or less: how files are stored and displayed is 
basically yet to be defined(?). Since this a huge task, perhaps it's 
better to walk around it and just make a simple UI displaying the data 
without displaying the sources as a first step?

I have run f-r on the compete rawhide distribution, so there is some 
data to feed it with :)

If this thing should roll (which I'd prefer, for sure...) I think we 
need something like this running asap. Displaying the source files is 
nice, but could be next step IMHO.

--alec