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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
