[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

non-gnu elpa issue tracking

From: Boruch Baum
Subject: non-gnu elpa issue tracking
Date: Wed, 9 Dec 2020 07:55:16 -0500
User-agent: NeoMutt/20180716

I've read sumaries of Richard Stallman's presentation about the
proposed, and in comparing it with Stefan Monnier's in-progress web
interface, have several suggestions:

1) License disclosure: The summaries indicate that RMS is open to having
   the repository host packages bearing *any* free license, but there
   may be users who are pickier, so a package's license should be
   disclosed prominently on the listing page and the package detail

2) The acceptance or candidacy process for each package should be
   documented in some discrete method. Melpa does this using github's
   pull request feature, which documents the entire conversation related
   to the process of accepting a package.

3) After a package is initially accepted to the repository, the
   summaries of Richard Stallman's presentation indicate that subsequent
   commits or releases may be rejected or modified. That record should
   also be documented. Debian does this using its own package tracking

   Here's an example of it in action (for the package 'bash'):

   It's source code is available on its 'salsa' repository (gitlab?):

   Debian's experience and the automation of its infrastructure might be
   useful to adopt in-toto even if its not an absolutely perfect match
   because it's a turnkey solution and is actively maintained (eg. they
   may accept feature requests).

4) There's no link on the repository page[1] to the software being used
   to generate it, and the forge at which it is being developed. Having
   that would make the infrastructure friendlier for pull-requests, bug
   reports, and other feedback.

[1] https://elpa.gnu.org/nongnu/

CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

reply via email to

[Prev in Thread] Current Thread [Next in Thread]