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: GNU ELPA package discoverability Date: Sat, 23 May 2020 23:51:43 -0400 Message-ID: References: <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <2e630dc7-ba1d-e4c9-74b3-4da976db1e82@yandex.ru> <20200522081318.GA299926@odonien.localdomain> 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="55754"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theophilusx@gmail.com, Emacs-devel@gnu.org, mail@vasilij.de To: Vasilij Schneidermann Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 24 05:52:14 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 1jchgM-000EOD-9a for ged-emacs-devel@m.gmane-mx.org; Sun, 24 May 2020 05:52:14 +0200 Original-Received: from localhost ([::1]:38514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jchgL-0000lz-9Q for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 23:52:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59916) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jchfu-0000MS-MJ for Emacs-devel@gnu.org; Sat, 23 May 2020 23:51:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54466) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jchfs-0001BO-ED; Sat, 23 May 2020 23:51:44 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jchfr-0000BC-IV; Sat, 23 May 2020 23:51:43 -0400 In-Reply-To: <20200522081318.GA299926@odonien.localdomain> (message from Vasilij Schneidermann on Fri, 22 May 2020 10:13:18 +0200) 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:251297 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. ]]] > This sounds like an interesting proposal. A similar system is used for the > package management system of the Arch Linux GNU/Linux distribution: > - core repository: Essential packages for setting up a base system. > - community repository: Packages the community considers essential, adopted > by a "Trusted User" (TU) to ensure quality standards and ongoing > maintenance. > - Arch User Repository (AUR): External repository allowing anyone to submit > packages in source form, these can be installed using an AUR helper > program (which themselves are part of the AUR). If this is simply a matter of three different levels of maintenance, I see no reason we can't have all three for ELPA packages. But it is rather complicated, and managing that will take work. Having just two levels may be enough, and it is much simpler. Arch GNU/Linux does not face the issue of making sure that packages don't recommend nonfree software. Indeed, it includes nonfree programs. But that issue is part of our core goal. We cannot follow their example into working against our principles. >From that rough description of the Arch User Repository, I get the impression it doesn't have any step at which that checking would be done. So we would have to add that. > - Users familiar with commit access to that "second ELPA" identify important > community packages and contact their maintainers. > - Packages are reviewed for their overall quality (license, release policy, > code style, ...). > - Package releases are tested and included in that "second ELPA". > - Packages of exceptional quality may be promoted to GNU ELPA. GNU ELPA will require copyright assignment. It will be only for packages that, aside from practicalities, are like core Emacs. > - The naming is important. GNU ELPA is a bit unfortunate as a name, it > consists of a license identifier and a technology. GNU is an operating system, and the project to develop it. I wrote licenses for it, so we call them "GNU licenses", but those licenses are not the meaning of the name "GNU". GNU ELPA is the ELPA that the GNU Project supports. Nonetheless, I take your point. > Perhaps it's late, but a rename to ensure consistency with the "second > ELPA" would help with adoption of the proposal. It is somewhat late, but not impossible if we find a clearly better name. > - The exact relationship between GNU ELPA, the "second ELPA" and > community-provided ELPA repositories needs to be clarified and clearly > documented in the manuals to help users choose the appropriate > repositories to install packages from. If "community-provided ELPA repositories" means those that include packages that depend on nonfree programs, we can't "work with" that. The only thing we can legitimately say about them is "don't go there." -- 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)