I see your point,
However I would subject it to our capacity to respond to ABRT crasher, do we have a measure as to how much quality do we bring thanks to ABRT vs a measure of how often and how badly ABRT impacts the experience?
I will give you an example, I have had a couple of crashers that brought ABRT to consume all my machine resources, rendering it unusable. The crasher itself is bad, but freezing the whole system because an app decided to crash is even worse than the crash.
From my POV it all boils down to figuring out if the ABRT guys are aware
about these issues and if they plan to fix them anytime soon.
On Mon, 2014-07-14 at 11:38 -0400, Christian Schaller wrote:
----- Original Message -----
From: "Alberto Ruiz" aruiz@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, July 14, 2014 4:38:24 PM Subject: Re: ABRT?
I think what you stated (+1 as a developer, -1 as a user) is pretty much how most workstation users feel.
I know for a fact that the ABRT team does work hard, so I don't really wan't to reflect on their efforts, however, if we have the choice in our hands (I don't even know if we do), I think we should probably write down all the negative impact that ABRT has on UX, try to solve it in the mid-run with the ABRT guys, and remove ABRT in the meantime. Because quite frankly, I rather have a nice user experience than crash reports if that's the tradeoff.
Well as annoying abrt can be I think nothing ruins the user experience more than crashers, so if abrt helps us fix more crashers/the most important crashers, I think that improvement in user experience probably outweighs the irritation of abrt.
Christian
So, the question is, do we have the ability to remove it without being in conflict with the other products?
Just my 2 cents.
On Mon, 2014-07-14 at 09:27 -0500, Michael Catanzaro wrote:
On Mon, 2014-07-14 at 16:10 +0200, Kalev Lember wrote:
As a developer, I absolutely love the retrace server, https://retrace.fedoraproject.org/faf/problems/hot/ . It gives an overview of the most frequent traces ABRT has seen and this is invaluable for prioritizing and fixing crashers that users are experiencing in real world. Also, bug reports filed with ABRT tend to be of high quality, which makes it easy to fix issues reported. I always tell everybody to submit crash reports when ABRT asks them to, since it helps us fix stuff.
Yes, this service is wonderful, though lately I've been seeing missing problem reports and wondering if it's working properly.
As a user, I hate ABRT with all my heart. The UI is confusing to me, it just never seems to work properly (perhaps that's because I run rawhide and ABRT developers don't focus their efforts there), and it also gets in the way of debugging crashes in my own stuff. So I tend to remove it from my systems and file bugs by hand instead, if needed.
My experiences are based on F20.
I don't find it gets in the way of debugging my own crashes, though, since by default it creates core dumps in the crashing processes' directory as long as you remember to set ulimit -c. I WILL find it gets in the way of debugging my own crashes in F21, since F21 finally enables systemd's wonderful coredumpctl tool. ABRT is going to conflict with that, but I bet this can be worked on. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
-- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop