How to proceed with MiniDebugInfo

[Jiri Moskovcak]

On 05/24/2012 11:24 AM, Alexander Larsson wrote:
> On Thu, 2012-05-24 at 11:17 +0200, Jiri Moskovcak wrote:
>> On 05/24/2012 11:07 AM, Alexander Larsson wrote:
>>> On Thu, 2012-05-24 at 11:22 +0300, Yanko Kaneti wrote:
>>>
>>> The duplication of effort less so IMHO, as different people are doing
>>> the work. If we don't do minidebug I will not be spending any resources
>>> on the ABRT server anyway. So, not doing minidebug will not affect ABRT
>>> positively, and doing it will not affect it negatively (in fact, it
>>> might have a slight positive effect as it can use the low quality info
>>> when offline). But still, as this is mainly a resource/project
>>> management disagreement it might make sense to have Fesco look at it
>>> too.
>>
>> In fact it will affect ABRT positively - the calltrace with function
>> names is a pretty good for duplicate checking, so ABRT will be able to
>> find the dupes in already filled bugzilla tickets without requiring the
>> full debuginfo.
>
> Well, theoretically it could do that by retracing the backtrace on the
> server. It seems much simpler and more efficient to just do that locally
> though, but this is partly where the disagreement is.
>

I know we could "retrace" the calltrace on a server to get the function 
names, but for the use case we want to use it it's critical to have it 
fast. And having it stored locally and available at the moment of crash 
is imho faster than retracing it on a server.

I actually don't see a reason (except the space, but the numbers doesn't 
look so horrible..) why not to have it. No one says it's going to be 
used in tickets created by ABRT in bugzilla and no one says we're going 
to force maintainers to work only with these "low quality" backtraces. 
ABRT can still require the full backtrace to create a bz ticket and I 
can easily imagine a situation where knowing just the function name 
helps me to find a problem. So what's the worry about?

Jirka