[Bug 735665] gst-validate should concatenate its issue reporting in some cases.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=735665
  GStreamer | gst-devtools | git

Thibault Saunier <tsaunier> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |tsaunier at gnome.org
     Ever Confirmed|0                           |1

--- Comment #2 from Thibault Saunier <tsaunier at gnome.org> 2014-09-05 14:11:55 UTC ---
(In reply to comment #1)
> The first problem to solve here is how can we detect than 2 reported issues are
> actually the same?
> 
> In this case, checking if report->issue and report->message are equals should
> be enough. But this implies that, for a specific issue, we assume that
> report->message will always be different for issues having different root
> causes. That's the case here as the message includes the address of the buffer,
> but can we rely on this for all the issues?

Currently we have a pretty simple logic to detect if a GstValidateReporter
already contains a GstValidateReport of the same kind.

I think that what is needed to implement that feature is to be able to instead
of blocking the repetition of an action for a particular monitor, it would be
to 'block' it for a particular 'branch/chain' of the pipeline. (actually you
would not inhibit the repetition but instead you would add the name of the
element to a list of monitor/GstValidateReporter + metadatas where that issue
happen on). I guess the simplest way of implementing that "per branch" issue
logic would be to just go up following the pipeline upstream checking each
monitor on the way. Then if one monitor has already notified that it received
that type of issue, add the information about that downstream monitor also
having the same issue on that specific report structure. And if we can not find
any similar issue upstream, report the issue. 

Also the report types already have the notion of "repeat" which aims at letting
the reporting system know if a particular issue should be repeated in the
runner if it happens several time (currently no issue type is repeatable iirc).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.