Re: non-gnu elpa issue tracking

[Thibaut Verron <thibaut.verron@gmail.com>]

Le jeu. 10 déc. 2020 à 12:23, Stefan Kangas <stefankangas@gmail.com> a écrit :
>
> Thibaut Verron <thibaut.verron@gmail.com> writes:
>
> > Would gitlab be acceptable, at the very least?
>
> There are no requirements that the git repository should not be hosted
> on Gitlab, Microsoft Github or any other place.  This is already the
> case on GNU ELPA, and NonGNU ELPA will not change that.

Thank you, that's a very useful clarification.

> > Am I correct to understand that if some developers decide that they do
> > not want their package included in non-GNU ELPA, the only way that
> > they can enforce this decision is to use a less permissive license for
> > future releases?
>
> Correct, that is in general how free software works.
>
> But they could also, you know, tell us that they don't want it included.
> There is no reason to suspect that it would not be taken into
> consideration.
>
> I don't think it is prudent to tie our hands in advance by saying that
> we will never, under any circumstances, distribute a package unless its
> maintainer wants to work with us.

I understand and agree with the intention behind both paragraphs, but
they could very easily come into conflict. :)

>
> > I thought the goal of non-GNU ELPA was to make MELPA necessary only
> > for non-free packages, and thus useless of the vast majority of users.
>
> AFAIK, the goal is to provide a curated and free package archive that
> can be enabled by default in Emacs.
>
> The aim is not to make MELPA "useless", in fact it would be better if it
> could become more useful, for example by not including packages that
> encourages the use of non-free software.

I didn't mean "useless" but "unnecessary". As of now, the easiest way
to install Magit or Projectile is by activating Melpa, which exposes
users to packages promoting non-free software. With NonGNU ELPA, a
large portion of users will never need to activate Melpa.

But for those who will need it, I suspect that those packages
promoting non-free software will be the reason.

If Melpa stopped including those packages, then they would find a home
in some other software repository and the situation would be the same
mutatis mutandis. But in any case, with NonGNU ELPA providing the
useful and purely free packages, users won't be accidentally exposed
to the ones promoting non-free software.

Anyway, that's only how I see it, and the issue is orthogonal to the
question at hand.

>
> > If "non-free" now includes all those packages whose developers don't
> > want to deal with issues outside of github, it can become a lot more
> > extensive.
>
> NonGNU ELPA has no rules detailing how a maintainer should deal with
> bugs.

That was in the context of the discussion: if there were to be a rule
that a package description on a gnu.org page cannot link to github, it
would force the maintainers to collect bugs and issues in another way
in addition to github.

So, again, thanks for the clarification.

> > As I said, hypothethical talk is not useful. Bring a package and ask
> > if such can be included. Let us see, that we do not create problems
> > out of nothing.

> Indeed.

For instance: https://github.com/Fuco1/smartparens
The readme and all files have multiple links to non-free websites.