Re: feature/package-vc has been merged

[Philip Kaludercic <philipk@posteo.net>]

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.

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

>> 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"?