A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg00850.html below:

Re: feature/package-vc has been merged

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4