Re: non-gnu elpa issue tracking

[Stefan Kangas]

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.

> I thought that the point of non-GNU ELPA was to bridge the gap between
> the emacs developers and the "community developers". But this kind of
> minor ideological changes, in my opinion, is more likely to antagonize
> developers.

To be clear, no such changes are planned.

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

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