emacs-devel
[Top][All Lists]
Advanced

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

Re: feature/package-vc has been merged


From: Björn Bidar
Subject: Re: feature/package-vc has been merged
Date: Sun, 13 Nov 2022 22:20:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Philip Kaludercic <philipk@posteo.net> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> I translate this my self: Yes both sources contain only free software,
>> but both contain software that interacts with non-free software.
>
> I believe that Stefan explained this, in distinguishing between software
> that you have to run on your own system and a fixed service that runs on
> non-free software.  A web browser is not at fault when requesting a
> website from a non-free web server.

What if the software only implements non-free standards such as Exchange?

>> Anyway you don't have to write in German just for me, it's fine.
>
> Ok.
>
>>> What do you have in mind specifically when you say "modern"?
>>>
>>> The Guix people have been using a separate different front end that
>>> /looks/ more modern, that still is debbugs AFAIK:
>>> https://issues.guix.gnu.org/, and the source code is here:
>>> https://git.elephly.net/gitweb.cgi?p=software/mumi.git.
>>
>> Yes something like your example, a ui that allows contribution without
>> email and looks more modern. Both debbugs and the mailman2 that used by
>> Gnu also doesn't scale/look good on high dpi screens.
>> Mailman2 is EOL in any case.
>
> Then it might be worth convincing whoever is responsible to try setting
> up mumi.  There has also been the discussion of moving to SourceHut,
> which should also fix the issues you have.

ok. For me anything is fine but I there are others.

>>> Richard went into that issue in a parallel thread just yesterday:
>>> https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg00792.html:
>>>
>>>   Our general policy makes a subtle distinction between these two
>>> cases:
>>>
>>>   1. If a nonfree program FOO is not well known, we don't even
>>> mention that
>>>   it exists.  Because we don't want to promote using FOO.
>>>
>>>   2. If a nonfree program FOO is well known and widely used,
>>> something to
>>>   help and encourage FOO's users to use some GNU packages along with
>>> FOO
>>>   is good.
>>>
>>>   3. Anything that would encourage the existing users of some GNU
>>> packages
>>>   to use FOO with them is bad.
>>
>> OK I don't see anything against cooperating with Gnu in Melpa, the only
>> difference is the barrier of entry for packages that interact with
>> non-free systems, especially the amount of questioning that a package
>> has go too but that is subjective I think.
>
> Are you saying that GNU ELPA or MELPA go through more "questioning"?


I'm saying that packages that interface with non-free formats or systems
have less questioning in Melpa.
In Elpa a package has to justify why it should be added when it
interfaces with non-free systems.

Br,

Björn



reply via email to

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