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 [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.
- 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
upstream: https://github.com/abrt/abrt/issues/609 and started working on
it (new update should be out asap)
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.
- 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
Regards,
--Jirka
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@xxxxxxxxxxxxxxxxx 871 37 908
kernel-maint@xxxxxxxxxx 680 63 743
xgl-maint@xxxxxxxxxx 704 14 718
bnocera@xxxxxxxxxx 635 20 655
otaylor@xxxxxxxxxx 637 15 652
tbzatek@xxxxxxxxxx 476 20 496
rstrode@xxxxxxxxxx 460 28 488
mclasen@xxxxxxxxxx 398 25 423
dakingun@xxxxxxxxx 373 9 382
dmalcolm@xxxxxxxxxx 358 7 365
[1] I know there can be plenty of metrics, I just used this one.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
