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:53:12 -0800 (PST) Message-ID: <502c95ed-28c7-4fb5-9149-6bddc9eb514a@default> References: <20191117113054.49837.qmail@mail.muc.de> <87y2wexsv1.fsf@telefonica.net> <20191118175639.08d02820@jabberwock.cb.piermont.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="11946"; mail-complaints-to="usenet@blaine.gmane.org" Cc: larsi@gnus.org, stefan@marxist.se, moasenwood@zoho.eu, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 29 08:03:44 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 1iaaJc-0002wD-0P for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2019 08:03:44 +0100 Original-Received: from localhost ([::1]:55384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaaJa-0000Yv-Tb for ged-emacs-devel@m.gmane.org; Fri, 29 Nov 2019 02:03:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53710) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaaFw-0000Vk-VE for emacs-devel@gnu.org; Fri, 29 Nov 2019 02:00:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaa9Z-0003Aa-9M for emacs-devel@gnu.org; Fri, 29 Nov 2019 01:53:22 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:38064) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaa9Y-00031M-WF; Fri, 29 Nov 2019 01:53:21 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAT6n1eQ036294; Fri, 29 Nov 2019 06:53:16 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=CHW7OjsmXIys/lRS95nhNK0cAE9Lnns4PoBa25j5EzI=; b=os5fF/KzNn8jCCUig9u9JEZIqNN8loszL2nfq+6Odo2LmT0jRU3yAcdEX7U55QAJ27Xf B4x9QFwoygY16x59oPgo/5DOSpSQuyM8BEJecU9uVG1DxnJqTWURMPwny6/MtjAR8Uev +RMDROm6gCKgQ6dStMqGX2K3DkNZ1Qt8eW7zDRjYdR5nNitFuiKWqx4YgZN61zV1mjwp DM+YgahQ621uLqOyzzO478txXKe6+9ebbLjxCoXkbTY/9SSZuSX9NH9P/SuFm/TIbR9T hKCrwpjHpnilH9Zh+Rc3ZDLjKcnhTvMPdNfl0rU85r8mxuUSCvFMzEqFHmLrSML2agGs TA== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2wev6upsmh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Nov 2019 06:53:16 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAT6nSKF158546; Fri, 29 Nov 2019 06:53:15 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2wjh122pyf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Nov 2019 06:53:15 +0000 Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAT6rDS4024519; Fri, 29 Nov 2019 06:53:13 GMT In-Reply-To: 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=29 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=594 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911290058 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=29 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=652 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911290058 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 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:242860 Archived-At: > It is not immediately obvious what interface is best > to help various users with various situations ask > for what is best for them. It would be useful for > people to explore various ways. Agreed. Please do explore. As I said earlier: > Just an idea. Not sure if it's worth implementing, > but I think it would be useful. Good. All ideas are helpful. And still earlier: > I have two ideas for changes: > * Ask whether to include this part. > * Inform people that they could delete it if > they don't want it posted to the bug tracker. Or offer the choice [between those] - via an option. So yes, let's explore various ways to help users provide what they want to provide and to be aware of what they're sending. You also said: > I think the simplest possible way is to identify > the data that might be sensitive, and help users > exclude all that data. I don't disagree with that. How best to help them exclude "that data", i.e., any data they might feel then don't want to send?