From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Crash recovery strategies Date: Sun, 3 Jan 2016 17:34:41 -0800 (PST) Message-ID: <9b317b53-5212-4004-b28b-87913da2cc07@default> References: <83mvu1x6t3.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.fsf@gnu.org> <567C25B1.3020101@dancol.org> <56892FD6.8040708@dancol.org> <568988EE.3010205@dancol.org> <56899278.9000007@dancol.org> <56899EAC.1030408@dancol.org> <5689ACFC.5050407@cs.ucla.edu> <5689AEE8.7030707@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1451871322 2943 80.91.229.3 (4 Jan 2016 01:35:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jan 2016 01:35:22 +0000 (UTC) To: Daniel Colascione , Paul Eggert , Eli Zaretskii , Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 04 02:35:10 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aFu3B-0005h5-B2 for ged-emacs-devel@m.gmane.org; Mon, 04 Jan 2016 02:35:09 +0100 Original-Received: from localhost ([::1]:43532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFu3A-0006D7-Gf for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 20:35:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFu36-0006Ct-V0 for Emacs-devel@gnu.org; Sun, 03 Jan 2016 20:35:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFu36-0006GJ-3X for Emacs-devel@gnu.org; Sun, 03 Jan 2016 20:35:04 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:20035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFu30-0006Es-D6; Sun, 03 Jan 2016 20:34:58 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u041YgBa018755 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2016 01:34:43 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u041Yg3f012998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2016 01:34:42 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u041Ygwa026216; Mon, 4 Jan 2016 01:34:42 GMT In-Reply-To: <5689AEE8.7030707@dancol.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197556 Archived-At: > More generally, how do we feel about automatically sending crash reports > to the FSF? Of course, we'd send reports stripped of personally > identifiable information, as is standard practice. I, for one, might be against that, unless the user explicitly agrees to it ahead of time somehow, and we let the user know exactly what (kinds of) info will be sent. What one person considers personal information (whether or not it identifies the person) another person might consider not to be so. IOW, it might depend on just what is meant by stripping. For example, the info that is gathered automatically now for inclusion in a bug report could be seen by a user to include more info than s?he might want. Is there a reason to send the report automatically? Is it just to avoid interacting with the user because any further interaction might interfere with the state to be reported (in which case, take the state snapshot before asking)? Or is it because such interaction could itself be problematic (in which case just do without that particular report)?