<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 17, 2014 at 10:52 AM, David Tardon <span dir="ltr"><<a href="mailto:dtardon@redhat.com" target="_blank">dtardon@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class=""><br>
On Wed, Jul 16, 2014 at 12:22:51PM +0300, Elad Alfassa wrote:<br>
> On Wed, Jul 16, 2014 at 11:59 AM, Jiri Eischmann <<a href="mailto:eischmann@redhat.com">eischmann@redhat.com</a>><br>
> wrote:<br>
</div><div class="">> > ad 1) I think ABRT offers two ways to create backtraces etc. Either on<br>
> > their server or on your machine. AFAIK ABRT started preferring the<br>
> > former option because users don't have to install all the debug tools to<br>
> > report a problem, but if their server is overloaded it may take ages to<br>
> > create a bug report.<br>
> ><br>
><br>
> Some users have extremely slow upload speeds, so uploading a 100MB core<br>
> dump takes ages.<br>
> Downloading the debuginfo is also a problem for people with slow download<br>
> speed.<br>
<br>
</div>So maybe these users might prefer not to use abrt? There are also users<br>
with very high upload/download speeds, for whom neither is a problem...<br>
<div class=""><br></div></blockquote><div>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.<br>
</div><div>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
><br>
> Fedora executables and shared objects are compiled with a minimized form of<br>
> debuginfo. It allows creating a simple backtrace even when you don't have<br>
> the huge -debuginfo packages installed, when the only downside for this<br>
> case is that you'll not have source line names, only symbol names and the<br>
> name of the shared object they came from.<br>
><br>
> I think that if we want to improve ABRT's UX, we need to get rid of the<br>
> retrace server AND the debuginfo downloading, an generate the backtrace for<br>
> the bugreport without these.<br>
<br>
</div>Yeah, why not. Because it is already hard to get an idea about the<br>
reason for the crash from the backtrace, let's make it even harder!<br>
</sarcasm><br>
<br>
Frankly, rather than that, it would be much better to disable abrt bug<br>
reporting completely.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> The backtrace will take less than a minute to generate (in most cases) and<br>
> is better than nothing.<br>
<br>
</div>No, it is not. From packager's POV it is worse than nothing, as it<br>
forces me to spend time on the bug, even though the expectation of<br>
successuful identification of the problem is practically zero.<br></blockquote><div><br></div>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.<br>
</div>-- <br><div dir="ltr">-Elad Alfassa.</div>
</div></div>