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: Thu, 14 May 2020 01:03:43 -0400 Message-ID: References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <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> <83h7wl86sq.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="39423"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 14 07:05:55 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 1jZ64B-000A9h-8p for ged-emacs-devel@m.gmane-mx.org; Thu, 14 May 2020 07:05:55 +0200 Original-Received: from localhost ([::1]:41112 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZ64A-0007XB-9M for ged-emacs-devel@m.gmane-mx.org; Thu, 14 May 2020 01:05:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58304) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZ625-0004IV-6i for emacs-devel@gnu.org; Thu, 14 May 2020 01:03:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54015) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZ624-0007Dl-G2; Thu, 14 May 2020 01:03:44 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jZ623-0005LH-By; Thu, 14 May 2020 01:03:43 -0400 In-Reply-To: <83h7wl86sq.fsf@gnu.org> (message from Eli Zaretskii on Tue, 12 May 2020 19:19:33 +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:250191 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. ]]] > I could agree to that, but I wouldn't agree to drop all of the > requirements. And even if we loosen some of them, it's already > problematic: the contributors of code for the core, which are > generally required to adhere to all of the requirements, could > rightfully feel they are treated unfairly, even though developing the > core benefits Emacs more than an unbundled package. That is an important point. Relaxing any standard for part of the spectrum tends to lead to pressure to relax it elsewhere too. But there may be ways we can reduce that pressure. One idea is to make a clearer distinction between packages. For instance, we could divide GNU ELPA packages into two repos, or two classes of inclusion, with different standards. There are various ways to work out the details. Another idea is to recruit someone to promise to clean the package up, before installing it. Then we would install the package tentatively. If the person who promised does not do the work, we could say, "We tentatively added XYZ to GNU ELPA after someone promised to clean it up, but perse didn't do the work. We can keep it tentatively in GNU ELPA if someone else commits to do that work." For cleanups that are purely technical, this could be effective to get them done. It would be useful to record, with each tentative package, a target date for the work, and a deadline further away, at which point we would recruit someone else or delete it. Vital for either of these ideas to be effective is to _show_ users these facts reasonably often if they use GNU ELPA. Information in a page they can look at if they are curious will not do the job. One idea is to make package.el show the information to anyone who installs the package. Also, it could ask for confirmation on installing a tentative package. Is there a way to ask for confirmation more often than that, but not too often? WDYT? -- 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)