Re: non-gnu elpa issue tracking

[Stefan Kangas]

Boruch Baum <boruch_baum@gmx.com> writes:

> 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
>    page;

Are there any packages out there that don't use the GPL?  Could you
point us to some examples?

> 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.

Could you be more specific?  Do you mean that we should document it
somewhere, or do you mean something else?

> 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
>    software.
>
>    Here's an example of it in action (for the package 'bash'):
>      https://tracker.debian.org/pkg/bash
>
>    It's source code is available on its 'salsa' repository (gitlab?):
>      https://salsa.debian.org/qa/distro-tracker
>
>    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).

"Debian's infrastructure" is massive and has many moving parts.
Do you suggest that we should adopt all of that wholesale?

> 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.

I assume that there will be a landing page similar to the one on
elpa.gnu.org.