Re: abrt + X Error => zillions of duplicate bug reports?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/25/2009 09:02 AM, Michal Hlavinka wrote:
On Tuesday 24 November 2009 22:49:53 Matěj Cepl wrote:
Dne 24.11.2009 22:37, Adam Williamson napsal(a):
We came up with several possible courses of action. First, we
acknowledge that abrt team is working on improving duplicate detection,
but Matej noted that this is intrinsically hard work and abrt will
likely never be able to eliminate or even come close to eliminating
duplicate reporting.

What's the technical limitation to coming close here?  It seems likely
that there will be some edge cases, but I would think that the majority
of cases aren't all that exceptional, and are fundamentally
straightforward to work out.

Don't ask me, I am just a humble bug triager (putting abrt developer on
CC of this message). What I can say is that even though I can see abrt
devs work hard to eliminate duplicates, they don't succeed much.
Apparently eliminating duplicates of bugs from beasts like Firefox or
OpenOffice is excessively hard.

Afaik, there are several projects with some crash/exception handling on top of
the stack. This makes it more difficult to find out where something actually
crashed. I think solution to this is more plugins/individual configurations.

Something like /etc/abrt/conf.d/<package_name>.conf

with<package_name>.conf content something like this (of course with better
format ;) :

refuseif()
{
   IF backtrace contains adobe flash THEN RefuseReporting("This crash is caused
by proprietary blob, we can't fix it. Try to contact adobe");
   ELSE IF ....

   return OK;
}

cropbacktrace()
{
   remove<packagename>'s crash handler from top of the backtrace
}

And abrt will call these methods if they are defined.

Just my 2 cents


Something like this is planned for the new dupechecker - it will allow maintainers or triagers (or anyone) to write simple rules (scripts) to detect duplicates based on their experiences. It's not possible for us (ABRT team) to know every single program and write the duplicity checker for it. Btw, every package maintainer can write his own plugin (it's really simple) to analyze the stacktrace and detect dupes in his application as the maintainer knows the code better than we do and knows what to look for.

Jirka
begin:vcard
fn:Jiri Moskovcak
n:Moskovcak;Jiri
email;internet:jmoskovc@xxxxxxxxxx
x-mozilla-html:FALSE
version:2.1
end:vcard

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux