From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Proposal for an Emacs User Survey Date: Mon, 19 Oct 2020 08:46:00 -0700 (PDT) Message-ID: References: <4a1188f8-9864-54c0-ae6f-5f32102d9757@gmx.com> <20201011073553.GA6784@odonien.localdomain> <20201011120840.GC2923@protected.rcdrun.com> <20201011125031.GC6784@odonien.localdomain> <20201012050418.GZ2923@protected.rcdrun.com> <20201013052736.GE31408@protected.rcdrun.com> <20201016130235.06218dae@argon> <87eelvplvh.fsf@posteo.net> <10bdf4ea-e365-cc3d-ec03-4348946fadbe@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20738"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mve1@runbox.com, bugs@gnu.support, thibaut.verron@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov , rms@gnu.org, "Philip K." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 19 17:50:17 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUXQO-0005E3-Dn for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 17:50:16 +0200 Original-Received: from localhost ([::1]:47232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUXQN-0000L4-BY for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 11:50:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUXOS-0007J9-Bc for emacs-devel@gnu.org; Mon, 19 Oct 2020 11:48:16 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:57508) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUXOQ-0007bW-Ag; Mon, 19 Oct 2020 11:48:15 -0400 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09JFZ1wD003866; Mon, 19 Oct 2020 15:48:11 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-2020-01-29; bh=2yAVTT2mpksedXVoOsmmA6f1tnqe3MFbbvJoD+xxErw=; b=FGopvYtb91K5CBRtLAcWA4jmaRShpjhuhnUsOQthWvjhsj3sgsfxGmFVmMvDf+mDzrpA nxa5uxac0jk2BuwCfyoLo/BZ5Bg+LLDelIpq4W/FNcZk2ur58sNOreobLOQUcaxuYN2k Vnw3M5xKR0TUvA3gueNKLu23HtUwWsAJw1xm7nTpBfFQ0hJxnuyE7xVvQp2JaxOpYzYb 5Yn60HTHG8bixYlL+AcWiku7mL7h+v2oeuH3nH/runNyZxXoRKbEP1CPqAwDOp6/55k3 TRSfe3omR0NsglffFVOVtYScGyp14gynT9AJtreR+ty3A8vcanYvKHiMgnqxW95aZIt/ Lw== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2130.oracle.com with ESMTP id 347p4apebh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 19 Oct 2020 15:48:11 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09JFV5Ik061430; Mon, 19 Oct 2020 15:46:10 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 348ahv429w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Oct 2020 15:46:10 +0000 Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 09JFk105023356; Mon, 19 Oct 2020 15:46:02 GMT In-Reply-To: <10bdf4ea-e365-cc3d-ec03-4348946fadbe@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5056.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9778 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 mlxscore=0 suspectscore=18 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190108 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9778 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 priorityscore=1501 clxscore=1015 malwarescore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190108 Received-SPF: pass client-ip=141.146.126.79; envelope-from=drew.adams@oracle.com; helo=aserp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 11:48:13 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258127 Archived-At: > MELPA to a large part consists of a database of "recipes", one for each > package that it builds and distributes. This tag can be put inside > recipes, and thus be controlled by MELPA maintainers, and not by the > packages authors themselves. >=20 > If we provide some well-defined criteria for such tags, and pick a > neutral-enough name, I don't see why the MELPA maintainers (who are > quite reasonable people IME) wouldn't go for it. Just a minor comment/question about this, which I think would be the first time such a thing would be happening: Do we really want to set a precedent that someone other than the code author fiddles with their code, adding comments or whatever? Sure, the maintainers of a repo are, in a way, administrators. But should such administrators be changing source code? Adding other code or whatever, to administer, label, treat, etc. the code is, at least conceptually, different from changing the source code itself. No, adding a field/tag in a comment is not a big deal. And yes, GPL code is open to modification. Still, is this a good door to open?