On 02/19/2013 01:13 PM, David Malcolm wrote:
On Tue, 2013-02-19 at 11:33 +0100, Miroslav Suchý wrote:
> I was curious what is the most buggy  package in Fedora and I made
> this chart:
> 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.
- Sorry to hear that, I can't find a bz ticket for this issue, so that
might be reason why it's not fixed yet, so I created one in our
and started working on
it (new update should be out asap)
I have a script that automates some of the workload of reassigning
component back to where the bug really is, but it currently requires
some manual intervention:
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:
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?")
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.
- sure thing that's exactly what is the "ABRT server" (aka faf) meant for
- please check your inbox I sent you email (a month ago) about
integration of those scripts to the server-side analysis and we can
start working on it
> And most overloaded assignee is:
> again click on "Total".
> Lazy to click? Here is Top 10:
> Assignee NEW ASSIGNED TOTAL
> nobody(a)fedoraproject.org 871 37 908
> kernel-maint(a)redhat.com 680 63 743
> xgl-maint(a)redhat.com 704 14 718
> bnocera(a)redhat.com 635 20 655
> otaylor(a)redhat.com 637 15 652
> tbzatek(a)redhat.com 476 20 496
> rstrode(a)redhat.com 460 28 488
> mclasen(a)redhat.com 398 25 423
> dakingun(a)gmail.com 373 9 382
> dmalcolm(a)redhat.com 358 7 365
>  I know there can be plenty of metrics, I just used this one.