On Tue, 2012-05-08 at 13:08 +0200, Miloslav Trmač wrote:
My take:
1) Developers of the software in question: Bluntly, the ~1-100 users
in the whole world shouldn't matter in our discussion - if they are
even running the RPM, they can and probably will install complete
debuginfo, enable logging and do other non-default things to make
their job easier; The Fedora defaults don't matter that much for them,
and the mini debuginfo is not that useful either.
I generally agree with this. When i'm working on an app I generally have
custom builds of it and its dependencies. However, at some point down
the dependency chain i start relying on distro packages, and it would be
kind of nice to have some info for that when e.g. profiling or
something.
2) Non-programming end-users. _This_ is the case that we need to
get
right by default. In many cases, a developer is lucky if the end
user ever sends any crash report, they often don't respond to
follow-up questions, and the problem does not have to be reproducible
at all. From such users we definitely want as full crash information
as possible (IOW, including the variable contents information) because
there won't be a second change to get it. The mini debuginfo is
therefore irrelevant, we need to steer users to the retrace server (or
to attaching full core files to reports, which has much worse privacy
impact).
I agree that we need to get this right, and that its the most important
problem. However, I don't agree with your reasoning. Its true that it
would be nice to have as much information as possible, and having the
retraced data availible when it works is nice. However, the details with
retracing, having to show the full backtrace letting you ack the
backtrace for privacy issue, the waiting for the retracing to happen,
etc, risks scaring the user away resulting in nothing being reported at
all.
Take this post for instance:
https://plus.google.com/110933625728671692704/posts/iFXggK7Q8KJ
It show exactly why this is a problem. We try to get more information,
but the result is less information.
A report based on the minidebuginfo already existing on the system will
give you a basic backtrace that is quite useful, and this should be
reportable with a single, fast operation just sending the data to the
server (as well as logging it to the system logs). The developer can
then do the retrace from that on the server side to get line numbers if
they are needed. We can also have an optional method of reporting that
gives the "full" stacktrace information, does the retracing over the
network and whatnot, but I don't think its a good idea to do by default.
BTW, the feature suggests mini debuginfo would be useful for
userspace
tracing - AFAIK such uses, e.g. systemtap, use the variable location
information very extensively, and would thus not benefit from mini
debuginfo.
True.