From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Vasilij Schneidermann Newsgroups: gmane.emacs.devel Subject: Re: GNU ELPA package discoverability Date: Fri, 22 May 2020 10:13:18 +0200 Message-ID: <20200522081318.GA299926@odonien.localdomain> References: <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <2e630dc7-ba1d-e4c9-74b3-4da976db1e82@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="34094"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tim Cross , Emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 22 10:14:04 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 1jc2od-0008kX-Vl for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 10:14:03 +0200 Original-Received: from localhost ([::1]:37528 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jc2oc-0002mt-Ue for ged-emacs-devel@m.gmane-mx.org; Fri, 22 May 2020 04:14:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jc2o5-0002MX-Ue for Emacs-devel@gnu.org; Fri, 22 May 2020 04:13:29 -0400 Original-Received: from mout-p-201.mailbox.org ([80.241.56.171]:48056) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1jc2o3-0007lH-PZ; Fri, 22 May 2020 04:13:29 -0400 Original-Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 49Szl63phyzQlKP; Fri, 22 May 2020 10:13:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id BK08aDnHJ2tW; Fri, 22 May 2020 10:13:19 +0200 (CEST) Mail-Followup-To: Vasilij Schneidermann , Richard Stallman , Tim Cross , Emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 7064D1784 X-Rspamd-Score: -5.84 / 15.00 / 15.00 Received-SPF: pass client-ip=80.241.56.171; envelope-from=mail@vasilij.de; helo=mout-p-201.mailbox.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/22 04:13:22 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001 autolearn=_AUTOLEARN 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:251200 Archived-At: --SUOF0GtieIMvvwua Content-Type: text/plain; charset=utf-8 Content-Disposition: inline > I'm thinking about making a second ELPA which won't require copyright > assignment. 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). There are several more repositories in this picture that I didn't mention for simplicity's sake. The idea is that new community packages are submitted to the AUR; if they prove to be sufficiently popular, a user may contact a TU for inclusion into the community repository. If the package doesn't prove to hold their ground, it can be removed from the community repository and added back to the AUR again. A TU typically maintains around 10-30 packages. Here's how I imagine the model to be adapted for our purposes: - 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. - Problematic packages (lack of upstream communication, ...) may be demoted and become a regular community package again. Some crucial points with this proposal: - The naming is important. GNU ELPA is a bit unfortunate as a name, it consists of a license identifier and a technology. It's not uncommon to contract it to just ELPA which causes confusion with the technology. Perhaps it's late, but a rename to ensure consistency with the "second ELPA" would help with adoption of the proposal. - There must be some obvious benefit to the "second ELPA" for users. The most obvious one is that there will be a vetted collection of packages installable out of the box. Perhaps more can be added, such as a guarantee of their overall quality. A common issue with community-provided ELPA repositories is the lack of quality assurance, for example upgrading all installed packages is a gamble, with breakage being a common side effect. If that "second ELPA" avoids this issue, that would make for a strong case. - 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. For example users caring about maximal stability would be advised to stick to the official ELPA repositories, but users seeking to install any kind of packages should look into community repositories, with the appropriate disclaimers. Vasilij --SUOF0GtieIMvvwua Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEE0dAcySl3bqM8O17WFmfJg6zCifoFAl7HiZAACgkQFmfJg6zC ifqR6Qf/f9Pi8XYvg76Nor8SsXAkZsFF69oULbdrva/r0Mn4OtQaF7BMU2G6EJno LXCoL11ykwXTlX0CKsuKpttLQVlH4wzfJEbhydeUvXUxIkV2ygcNVzzx/clVP+X7 5FvJvAQEiNgzYQSDHIxccsQTyH6bazqsx5+FurM44IQ0Fah+BoZ0GO6vkTbFEZj9 iinqACwdPhaxSIaPCfGVuLU193H5V3Ov9coED9We/BoXTg/QjEnxykWgEHH7tu7D HZwpy3EUh8855T+phDtTrbvtVEwmGrWwkMCihGVSe5i+IBclJbx3/JamWPTZqkFe k6VdXdsLUIkV8aXtVs0yHsvNB9lggQ== =KLBZ -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua--