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.
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(a)redhat.com>
> To: "Discussions about development for the Fedora desktop"
> 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
> 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
> > > 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(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/desktop
> Alberto Ruiz
> Engineering Manager - Desktop Applications Team
> Red Hat, Inc.
> desktop mailing list
Engineering Manager - Desktop Applications Team
Red Hat, Inc.