emacs-devel
[Top][All Lists]
Advanced

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

Re: non-gnu elpa issue tracking


From: Thibaut Verron
Subject: Re: non-gnu elpa issue tracking
Date: Thu, 10 Dec 2020 10:14:50 +0100

Le jeu. 10 déc. 2020 à 09:32, Jean Louis <bugs@gnu.support> a écrit :
>
> * Thibaut Verron <thibaut.verron@gmail.com> [2020-12-10 02:23]:
> > >
> > > My opinion is that non-GNU ELPA and GNU ELPA both should never point
> > > to any website that has any proprietary Javascript or promotes
> > > proprietary software, specifically hyperlinks to Github better be
> > > removed completely.
> > >
> >
> > Without backlinks to the original repositories, how will people know where
> > to report bugs with packages installed from non-GNU ELPA?
>
> My opinion is that nothing offered within Emacs, be it ELPA packages
> or now non-GNU ELPA packages should guide users to any non-free
> software, especially not websites with non-free Javascript like
> Github.

Would gitlab be acceptable, at the very least?

>
> Author name should be there, email address and there can be URL as
> per: (info "(elisp) Simple Packages")
>
> I would change that URL to point to non-GNU ELPA repository as it
> becomes not only plain distributor but slight fork of the
> package. There is nothing wrong with it. People can still use author's
> name and email to report directly.

I personally would be annoyed if users started reporting bugs directly
to my e-mail. I cannot imagine how it would be for high-traffic
packages.

And what about packages with extensive guidelines for reporting bugs?
Should they now include those guidelines in the package description?
And would you amend those guidelines to remove references to github,
too?

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.

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?

I don't think that we want to encourage such a choice.

> Remember that this does not prevent other users of any other website
> such as MELPA to use their hyperlinks how they like. T
>
> This opinion is for specifically for Emacs that should never point to
> non-free websites and relates to ELPA as well.
>
> So I do not see any real problem there. Those using MELPA will do what
> they wish.

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.

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.

> And those using non-GNU ELPA would report there where
> developers decide, but not on Github, provided this type of proposal
> is accepted.

What is "there" in this context? And who are "developers"?



reply via email to

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