Abrt (was Re: Most buggy packages)

[David Malcolm]

On Tue, 2013-02-19 at 11:33 +0100, Miroslav Suchý wrote:
> I was curious what is the most buggy [1] package in Fedora and I made 
> this chart:
> 
> http://tinyurl.com/bx6brjh
> 
> Click on "Total" and you get it sorted from most buggy to least buggy. 
> (I do not know if this sort flag can be made part of URL).
> 
> Lazy to click? Here is Top 10:.
> 
> Component  	NEW	ASSIGNED	TOTAL
> Package Review	943	384	1327
> kernel		884	118	1002
> gnome-shell	619	15	634
> anaconda	463	85	548
> xorg-x11-server	439	15	454
> yum		335	14	349
> python		334	5	339
> tracker		294	8	302
> control-center	205	1	206
> rhythmbox	202	1	203

How many of these bugs have "abrt" in the subject?
For Python's NEW bugs its about 2/3rds of them.

abrt consistently gets the component wrong for Python bugs; initially
any time a Python script segfaulted (thus crashing /usr/bin/python) abrt
assigned the component as python.  For a while this was fixed, and it
filed the component as whatever the bottom of the stack was.  But it
regressed a while back.

I have a script that automates some of the workload of reassigning the
component back to where the bug really is, but it currently requires
some manual intervention:
http://fedorapeople.org/cgit/dmalcolm/public_git/triage.git
so inevitably I don't run it on every bug that comes in every day, and
so I gradually get behind.

Of course, architecturally, this is completely bogus - it's insane for
bugs to be filed in bugzilla for segfaults and for me to be running a
script when I get emails in my inbox to try to triage them.
What we really should be doing is have abrt report crashes to a
dedicated crash-reporting db (I believe the retrace server is this), and
the crash-reporting db should load the coredump with the right debuginfo
packages, and triage accordingly.

In particular, I think the right way for retrace server to triage is to
run Python code embedded within gdb.  There are a ton of little
heuristics about such code:
http://fedorapeople.org/cgit/dmalcolm/public_git/triage.git/tree/rules.py
that need to run server-side.  In particular, for scripting languages,
it's most useful to be able to extract the script-level backtrace from
the C-level stack (i.e. "what was the Python code doing?")
http://fedorapeople.org/cgit/dmalcolm/public_git/triage.git/tree/backtrace.py#n46
has some smarts for doing this purely from a textual backtrace from gdb,
but running code like this directly within gdb on the retrace server
would likely get better results.


> And most overloaded assignee is:
>    http://tinyurl.com/a39bawg
> again click on "Total".
> 
> Lazy to click? Here is Top 10:
> 
> Assignee		NEW	ASSIGNED	TOTAL
> nobody at fedoraproject.org	871	37	908
> kernel-maint at redhat.com	680	63	743
> xgl-maint at redhat.com	704	14	718
> bnocera at redhat.com	635	20	655
> otaylor at redhat.com	637	15	652
> tbzatek at redhat.com	476	20	496
> rstrode at redhat.com	460	28	488
> mclasen at redhat.com	398	25	423
> dakingun at gmail.com	373	9	382
> dmalcolm at redhat.com	358	7	365
> 
> 
> [1] I know there can be plenty of metrics, I just used this one.