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
