[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-gnu elpa issue tracking
From: |
Stephen Leake |
Subject: |
Re: non-gnu elpa issue tracking |
Date: |
Sat, 12 Dec 2020 12:46:07 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (windows-nt) |
Tim Cross <theophilusx@gmail.com> writes:
> On Sun, 13 Dec 2020 at 00:50, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>> > The non-GNU ELPA is supposed to be a repository for packages which are
>> GPL
>> > compliant and it is a reasonable expectation that those who make their
>> > packages GPL compliant do so because they support the philosophical goals
>> > of the FSF.
>>
>> The overwhelming majority of ELisp packages out there are hosted on
>> Github (that also applies to many GNU ELPA packages, many of them are
>> developed by long time contributors to Emacs), so I think the evidence
>> shows the above expectation doesn't hold at all.
>>
> Maybe. However, it could also be a combination of the fact github was the
> first free git hosting environment and is the better known one. Just
> because it is this way now doesn't mean it has to be. If the GNU/FSF
> doesn't take a clear position on this and do something to discourage the
> use of hosting environments that force the use of proprietary software,
> this will not change and eventually all we will have are the proprietary
> solutions. It may not have been the right decision to allow code which has
> assigned copyright to the FSF to remain on Github. However, as non-GNU ELPA
> is just getting started, now would be a good time to try and change
> things.
+1.
I think we should encourage people to move away from Github, for both
GNU and non-GNU ELPA.
Given that many ELPA packages are now on Github, we could have a
transition policy, with enforceable deadlines (ie, remove package from
*GNU ELPA if still on gitub after deadline). However, I doubt that the
Emacs project is capable of such a thing, or that we want to be.
So we are left with naming and shaming; in list-packages, show the
upstream repository along with the license and other info on a package,
and show unacceptable ones in red. That could still be a lot of effort
to categorize obscure hosts.
Disclaimer; my packages are hosted on Savannah, so any resolution of this
will have no direct impact on me.
--
-- Stephe
- Re: non-gnu elpa issue tracking, (continued)
- Re: non-gnu elpa issue tracking, Stefan Monnier, 2020/12/14
- Re: non-gnu elpa issue tracking, Eli Zaretskii, 2020/12/14
- Re: non-gnu elpa issue tracking, Stephen Leake, 2020/12/13
- Re: non-gnu elpa issue tracking, Richard Stallman, 2020/12/12
- Re: non-gnu elpa issue tracking, Vasilij Schneidermann, 2020/12/13
- Re: non-gnu elpa issue tracking, Richard Stallman, 2020/12/14
- Re: non-gnu elpa issue tracking, Jean Louis, 2020/12/14
- Re: non-gnu elpa issue tracking, Stefan Monnier, 2020/12/12
- Re: non-gnu elpa issue tracking, Tim Cross, 2020/12/12
- Re: non-gnu elpa issue tracking, Jean Louis, 2020/12/12
- Re: non-gnu elpa issue tracking,
Stephen Leake <=
- Re: non-gnu elpa issue tracking, Alfred M. Szmidt, 2020/12/12
- Re: non-gnu elpa issue tracking, Christopher Dimech, 2020/12/12
- Re: non-gnu elpa issue tracking, Tim Cross, 2020/12/12
- Re: non-gnu elpa issue tracking, Christopher Dimech, 2020/12/12
- Re: non-gnu elpa issue tracking, Richard Stallman, 2020/12/13
- Re: non-gnu elpa issue tracking, Richard Stallman, 2020/12/12
- Re: non-gnu elpa issue tracking, Michael Albinus, 2020/12/12
- Re: non-gnu elpa issue tracking, Dmitry Gutov, 2020/12/12
- Re: non-gnu elpa issue tracking, Richard Stallman, 2020/12/12
- Re: non-gnu elpa issue tracking, Christopher Dimech, 2020/12/13