search

abrt / faf

Platform for collection and analysis of packages and package crashes
GNU General Public License v3.0
46 stars 47 forks source link

Filtering when searching on problems should filter REPORTS #469

Open owtaylor opened 9 years ago

owtaylor commented 9 years ago

The search:

https://retrace.fedoraproject.org/faf/problems/?opsysreleases=121&component_names=gnome-shell&associate=__None&daterange=2015-10-03%3A2015-10-17

Shows me counts of crashes that occurred between October 3 and 17 against Fedora 23, for any problem that ever occurred for gnome-shell. For example, it shows 17 crashes for the super-generic problem:

https://retrace.fedoraproject.org/faf/problems/bthash/?bth=0264dc71069afdca697f4b4f8086ed7ae3f67425

Even though gnome-shell probably never crashed in that manner for Fedora 23 in that time period.

To me, this is unexpected - why do I care if another problem is crashing in this fashion now, if gnome-shell only crashed that way 2 years ago?

Wouldn't it make more sense, if in problems.py:query_problems() , the filters on component_ids/associate_id/arch_ids/etc. were applied to the reports in the rank query, rather than the final query?

Even if the aggregation across components is real and not spurious like the example above, when someone is filtering, they presumably are interested in knowing what problems are currently affecting a component or architecture.

sorki commented 9 years ago

Yes, applying filters on rank_query seems more reasonable as it won't include include problems that occurred long ago but no longer manifest in filtered component. I'll try to switch filtering to work on rank_query. Thanks!