On Wed, Apr 22, 2009 at 06:01:55PM -0000, Matt Zimmerman wrote: > On Wed, Apr 22, 2009 at 05:40:28PM -0000, Steve Beattie wrote: > > Being able to correlate when a crash occurs with other event in logfiles > > is usually pretty important. In the bug I linked to, the person > > attempting to diagnose the issue had a hypothesis that the bug had > > occurred during an upgrade and not after the reboot; however, the only > > way to verify when the crash actually occurred was to look at the date > > stamp on the crashfile itself to confirm or deny that hypothesis. > > > > I share your concern with not overwhelming triagers with all the > > information available when a bug is reported; perhaps the dropped > > information could be combined into a separate attachment (e.g. > > CrashDetails) so that it doesn't clutter the bug's description but is > > available should it be necessary for diagnosing the bug? > > I assume Martin subscribed me because the suggestion to remove it came from > me (I don't quite recall). FWIW, I have no objection restoring it if it's > useful.
A lot of the information that apport collects isn't generally useful... except when it is. As a specific example, consider the contents of /proc/PID/attr/current -- for 99% of bugs, this is going to be uninteresting information, but if it actually contains an apparmor policy name or an selinux context, you need to take that into account when diagnosing the bug report as it may be the security policy that is causing the issue. (Though I have it on my todo list to add an apport collection item that looks for relevant audit events to attach to make it easier to identify such issues.) Until apport grows an expert system, the information that it should collect that is important to identifying the problem at hand is going to be a rough heuristic at best. So I really don't like the idea of discarding information that we've bothered to collect. I *do* think it makes sense to consider the presentation of the collected and submitted information separately from the data collection itself; I'm all for trying to limit the information that's included in the description to that which is commonly useful, but I think it makes sense to have the information that is uncommonly useful still available. This is why I suggested a separate attachment that contains such things; they would not clutter the main report (except for the attachment itself), but would still be available for diagnosis if needed. -- Steve Beattie <[email protected]> http://NxNW.org/~steve/ -- apport doesn't submit date information from crash reports https://bugs.launchpad.net/bugs/349139 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
