From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [ Date: Thu, 28 Nov 2019 22:32:05 -0800 (PST) Message-ID: References: <20191117113054.49837.qmail@mail.muc.de> <874kz0pa9y.fsf@gnus.org> <87sgmjyn60.fsf@gmx.de> <87imnezyt5.fsf@gmx.de> <481a1f16-d661-0f96-2f45-3d5ec9c1132e@yandex.ru> <871ru0t7p8.fsf@gnus.org> <7a7f8955-ec5f-4e1e-b258-19379588516a@default> <86sgmftq1m.fsf@zoho.eu> <87a78k8mka.fsf@osv.gnss.ru> <868so4bdsi.fsf@zoho.eu> <8736e9h7m1.fsf@gnus.org> <0100016eb5ccd5b0-959163b3-de2d-41a1-843f-f3fed80a5def-000000@email.amazonses.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="173756"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Lars Ingebrigtsen , Stefan Kangas , Richard Stallman , Emanuel Berg , Emacs developers To: Pankaj Jangid Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 29 07:36:24 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iaZtA-000j00-BP for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2019 07:36:24 +0100 Original-Received: from localhost ([::1]:55312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaZt6-00033Z-Ex for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2019 01:36:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38538) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaZpP-00032k-GP for emacs-devel@gnu.org; Fri, 29 Nov 2019 01:32:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaZpG-0006n3-Kd for emacs-devel@gnu.org; Fri, 29 Nov 2019 01:32:24 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:58078) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaZpG-0006Ac-9b; Fri, 29 Nov 2019 01:32:22 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAT6TEPM022239; Fri, 29 Nov 2019 06:32:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=x0vdandv0YWOMrLnHFVRfZmDIwVMQLyQejVz7YzeAUk=; b=AS4VsPx8Aw4IdRKa/EBL7ipnixeKvIfrXFl/3V5tRvE6WXvhpmNI/83ZzVBo5Orf8jMd 5DgjYVHl+90L+XLW0yP+Ycer5tabEmHsn7CTvUKU6R8iMYndEoKDV/bKvi+2kc7sFGaI P1nfg7tlICkngCYy30BUfE/hXdggDc2F5tZo592f5cSvqLl5KVM5QLsZ1x160A5xq5Pa pl+eTBf+ACyF0cpwjSwSoWw/zxcLllRuHm/gUHpED4fHZwyDmcLqeUJKKgg0SJYymwmm /mA4R8BNRJi2qpbMPaNXbfAbjPYDdst7NcmUXNKHzKiZ8PRmG6d+tElsRpYjDhk+XkWH ZQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2wevqqpsvn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Nov 2019 06:32:10 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAT6TCNS170792; Fri, 29 Nov 2019 06:32:09 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2wjh0sb7y7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Nov 2019 06:32:09 +0000 Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAT6W6Yh010467; Fri, 29 Nov 2019 06:32:06 GMT In-Reply-To: <0100016eb5ccd5b0-959163b3-de2d-41a1-843f-f3fed80a5def-000000@email.amazonses.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9455 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=919 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911290055 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9455 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=986 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911290055 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:242859 Archived-At: > > Let users decide. A simple option takes care of this. > > ... I see no reason why we wouldn't want to let users > > decide, in this regard - whether it's about privacy or > > any other reason a user might have for her preference. >=20 > It is not that simple. Many big corporates are fighting suites for > this. FB, Google all take users' consent and then they do all sorts of > things that the users didn't think they would do. >=20 > "Users' intelligence is very overrated", my opinion. That doesn't counter the position that users should be allowed to decide. That may be an argument for making the default behavior to be to exclude all, instead of to include all, of the info that we currently collection in a hard-coded way. The point is not that Emacs should automatically collect such info. The point is to give users an easy way express their preference. You are apparently making an argument that users shouldn't have to do anything to opt out of sending info. They should instead need to opt in to sending any such. I have no problem with that. What we do now is include everything by default, and if a user doesn't want to include some of that then she needs to explicitly, manually, delete it from what gets sent. And she needs to do that each time she sends a bug report. The point of my suggestion is to make it easy for a user to define her own default behavior. If the default for that user option should be to send no information then I'm OK with that too. > > What's the difficulty or downside to doing this? >=20 > Another, thing is that the current setup makes is really simple for an > expert user to report bugs. I just run "emacs -Q" and try to reproduce > the issue and if it exists, I just shoot the mail with just the steps > to reproduce without worrying about which commit, which packages > installed, > etc. I thought you were making an argument for not just including all such info. Now it sounds like you're arguing the opposite. I don't see the relation between the two. And I don't see what any of what's been discussed has to do with worrying about which packages are installed etc. In any case, any user, including any expert user, can easily have the same behavior as she has now. And in the patch I provided that would even be the default behavior, so the expert user would not need to change anything.