ubuntu-bugcontrol team mailing list archive

["Christopher M. Penalver" <christopher.m.penalver@xxxxxxxxx>]

Dear Ubuntu Bug Control, hello. I wanted to propose a modification of 
https://wiki.ubuntu.com/Bugs/Responses?action=recall&rev=380 that 
appears to work best for both reporters and responders when dealing with 
crash files.

First, I'd like to highlight the benefits of revision 380 that improves 
upon previous response iterations:
* Alerts the user to privacy and security issues when manually attaching 
.crash reports.
* Intends to ease the shock to original reporters of having their bug 
closed after taking the time and effort to report an issue.
* Includes a new troubleshooting tip of letting x server dump the core 
(now also documented in https://help.ubuntu.com/community/ReportingBugs).

With this in mind, new pain points for both reporters and responders 
have stepped up:
* Instead of the starting point for an issue being the crash is 
processed by Apport Retracing Service, and benefits of its technical 
output being observed, original reporters are confused into thinking 
having two reports opened by them, scoped to the same issue is helpful 
for either them, and/or responders.
* Not everyone cares to track crashes reports on Launchpad. These folks 
are just trying to be helpful by advising they got a crash message, may 
not know what happened when the window disappeared (it likely went to 
the Error Tracker), and it doesn't impact their use of the OS.
* Doesn't take into account when the original reporter has multiple, 
disparate crash files. This can cause the responder to attempt, in vain, 
to get the report down to one issue per report. This also creates a 
false expectation for original reporters, as they are now expecting a 
communication funnel through this one "meta" report about unrelated 
packages, problems with different root causes, and completely different 
maintainer teams.
* Delays the original reporter from seeing each issue addressed by the 
specialist of the respective packages. This is due to how the reporter 
and responders are ping ponging between the new and old report(s), 
and/or multiple crash files. If the manually filed report is closed, and 
the reporter files a crash report about each crash file separately, this 
creates a more direct approach, along with providing more relevant 
debugging information.
* Makes reporters dumpster dive LP#994921 to try to figure out what to 
do. Non-techy reporters tend to ask follow up questions if not advised 
precisely, defeating the point of asking them to review the URL.

Hence, I'm proposing the following change that preserves all the new 
benefits of revision 380, brings back some elements of revision 379 that 
dealt with some of these new pain points, and adds a bit to deal with 
the remaining pain points:
[START]
Thank you for taking the time to report this bug and helping to make 
Ubuntu better. However, your crash report is either missing, is manually 
attached, or challenging to deal with as a ".crash" file.

Please follow these instructions to submit a new report about all crash 
files found, that is best dealt with by the automatic retracer. First, 
execute at a terminal:
sudo rm /var/crash/* ; sudo apt-get update && sudo apt-get upgrade

If the crash is in Xorg, then edit the file /etc/gdm3/custom.conf from:
# Additionally lets the X server dump core if it crashes
#Enable=true

to:
# Additionally lets the X server dump core if it crashes
Enable=true

If you are running the Ubuntu Stable Release you might need to enable 
apport in /etc/default/apport and restart. Now reproduce the crash. Once 
reproduced, open a terminal and report all the crash files found via:
sudo ubuntu-bug /var/crash/FILENAME.crash

where FILENAME.crash is the file name of the crash report.

In the Ubuntu Stable Release, this will send the crash to Ubuntu's Error 
Tracker, instead of Launchpad. However, after reporting the crash to 
Ubuntu's Error Tracker, you would like to report a crash on Launchpad 
anyways (e.g. a severe issue occurs when the crash happens, you want to 
manually subscribe others to review the crash, you want to review the 
processed stack trace, etc.) one would need to edit the following file 
via a terminal:
sudo nano /etc/apport/crashdb.conf

and comment out the line:
'problem_types': ['Bug', 'Package'],

by changing it to:
# 'problem_types': ['Bug', 'Package'],

Save, close, and file the crash report via a terminal:
sudo ubuntu-bug /var/crash/FILENAME.crash

Also, please take care to avoid attaching .crash files to bugs as we are 
unable to process them as file attachments, and doing so is a security 
risk for yourself.

Hence, this report is being closed as the process outlined above will 
deal with this issue in the most efficient way.

Thank you for your understanding.
[END]

Finally, a note may want to be added above the response to confirm that 
in the case the crash file is missing, it is best to confirm first the 
reporter is generating crash files before closing the report due to 
missing crash files.

I wanted to run this by you in case there was something missed.

What do you think?

--
- Chris Penalver
E-Mail: christopher.m.penalver@xxxxxxxxx