ABRT?

[Elad Alfassa]

On Thu, Jul 17, 2014 at 10:52 AM, David Tardon <dtardon at redhat.com> wrote:

> Hi,
>
> On Wed, Jul 16, 2014 at 12:22:51PM +0300, Elad Alfassa wrote:
> > On Wed, Jul 16, 2014 at 11:59 AM, Jiri Eischmann <eischmann at redhat.com>
> > wrote:
> > > ad 1) I think ABRT offers two ways to create backtraces etc. Either on
> > > their server or on your machine. AFAIK ABRT started preferring the
> > > former option because users don't have to install all the debug tools
> to
> > > report a problem, but if their server is overloaded it may take ages to
> > > create a bug report.
> > >
> >
> > Some users have extremely slow upload speeds, so uploading a 100MB core
> > dump takes ages.
> > Downloading the debuginfo is also a problem for people with slow download
> > speed.
>
> So maybe these users might prefer not to use abrt? There are also users
> with very high upload/download speeds, for whom neither is a problem...
>
> So if a user has a slow connection and they get this notification, you
want them to spend hours only to understand "oh maybe my computer is too
slow for this" and give up? That's an horrible user experience and it makes
our product look bad.
If you build a product that works well on slow connections, it will work
well on fast connections too. However, if you build a product that only
works well on fiber-to-home connections, millions of people around the
world will find your product unusable. Many people use slow mobile
connections (EDGE, 3G), ADSL, or even dial up, and you can't just ignore
these people when designing the UX of your product.

>
> > Fedora executables and shared objects are compiled with a minimized form
> of
> > debuginfo. It allows creating a simple backtrace even when you don't have
> > the huge -debuginfo packages installed, when the only downside for this
> > case is that you'll not have source line names, only symbol names and the
> > name of the shared object they came from.
> >
> > I think that if we want to improve ABRT's UX, we need to get rid of the
> > retrace server AND the debuginfo downloading, an generate the backtrace
> for
> > the bugreport without these.
>
> Yeah, why not. Because it is already hard to get an idea about the
> reason for the crash from the backtrace, let's make it even harder!
> </sarcasm>
>
> Frankly, rather than that, it would be much better to disable abrt bug
> reporting completely.
>

> > The backtrace will take less than a minute to generate (in most cases)
> and
> > is better than nothing.
>
> No, it is not. From packager's POV it is worse than nothing, as it
> forces me to spend time on the bug, even though the expectation of
> successuful identification of the problem is practically zero.
>

You can debug crashes successfully even with such limited backtrace. Making
a random packager's life a little easier is not worth making our product
look bad. If you really need further details from a crash, you can always
ask the user to provide them.
-- 
-Elad Alfassa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20140717/81355715/attachment.html>