From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: PL support Date: Mon, 11 May 2020 23:17:19 -0400 Message-ID: References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <83k11ldpxs.fsf@gnu.org> <83imh5dnun.fsf@gnu.org> <83h7wpdms7.fsf@gnu.org> <83ftc9dm07.fsf@gnu.org> <0d678371-2df7-519e-5ec0-7e26bfa6ea34@gmail.com> <11dff979-002e-e03e-2e3e-cdb09fcc409e@yandex.ru> <8017be3d-a4ed-61eb-9bdb-9a95c77a0698@gmail.com> <3adf65ae-fd0d-4fee-adfd-e11d39a148fc@yandex.ru> <01e211df-acfb-fb8a-eedc-7cb439b64cd8@yandex.ru> <57491476-b7d1-ed1e-9eaf-bc45db607ae8@yandex.ru> <835zd2bf2h.fsf@gnu.org> <1c43f78b-2bc5-8c81-4a57-ba63bb721c85@yandex.ru> <83wo5i9z21.fsf@gnu.org> <83h7wm9uy7.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="100353"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, dgutov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 12 05:21:09 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 1jYLTf-000Pzt-RV for ged-emacs-devel@m.gmane-mx.org; Tue, 12 May 2020 05:21:07 +0200 Original-Received: from localhost ([::1]:51546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYLTe-0004qz-U5 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 23:21:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYLQ6-0007cQ-Qn for emacs-devel@gnu.org; Mon, 11 May 2020 23:17:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58360) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYLQ5-0004UO-V5; Mon, 11 May 2020 23:17:25 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jYLPz-0004GO-LH; Mon, 11 May 2020 23:17:21 -0400 In-Reply-To: <83h7wm9uy7.fsf@gnu.org> (message from Eli Zaretskii on Mon, 11 May 2020 21:40:16 +0300) 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:249929 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > No, we do nothing of the kind. Just because everybody and their dog > know what MELPA is and how to configure Emacs to use it, doesn't mean > _we_ told them. Exactly like we don't "recommend" using MS-Windows, > although quite a few of Emacs users do, witness the discussions on > Reddit as one example. We exist in a world in which lots of people willingly accept practices that our goal is to eliminate. That means we walk a narrow ridge. On one side, we could risk endorsing and supporting exactly the wrongs we denounce. On the other side, we risk becoming less popular. We want to avoid the latter, but we abolutely must avoid the former. Popularity is not success if it comes at the cost of abandoning our goal. Therefore we do not recommend MELPA. We do not mention the existence of about MELPA. If people know about it anyway, that is not our doing so we are not morally responsible. Eli explained the details what this means. Stefan wrote: > The way I see it, currently Emacs de-facto recommends to most of its > users to add MELPA to their `package-archives`. To balance between the two cliff edges, we have to recognize both edges. The expression "de facto recommends" denies one of them; it equates staying on the ridge with falling off. That would be self-defeating, so we insist on the distinction and do not equate those. > Of course, those few not-quite-libre packages could pose problems for > that since they go against some of our values, so maybe we should not > add MELPA itself, but the "libre-MELPA" subset (which someone will have > to create and maintain). That would not go against or morals. It is not absolutely out of the question. But it would have a big drawback of a different kind: we would effectively lose control over an aspect Emacs development. We want to keep some control over that, so we should not do this. If the shorthand.el approach does enable us to fix our namespace problems, that problem would be somewhat smaller; there would be a limit to how bad it could get. The other thing we try to achieve by recommending GNU ELPA and not other ELPAs is to motivate package developers to do the two things that enable us to put the packages into Emacs itself: sign assignments, and rework them to fit our non-moral standards. I think this is important. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)