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