Re: feature/package-vc has been merged

[Philip Kaludercic <philipk@posteo.net>]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>>>>
>>>>> Richard Stallman <rms@gnu.org> writes:
>>>>>
>>>>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>>>>
>>>>>> Please do not encourage people to load packages from MELPA.  MELPA
>>>>>> does not cooperate with us.  Not in legal matters, not in ethical
>>>>>> matters, and not in technical matters of development.
>>>>>
>>>>> What justifies this kind of gaslighting against Melpa? 
>>>>
>>>> Wikipedia defines gaslighting as:
>>>>
>>>>     Gaslighting is a colloquialism, loosely defined as manipulating
>>>>     someone so as to make them question their own reality [...]
>>>>
>>>> so I am not sure how this applies to this thread.
>>>
>>> I'm sorry but English isn't my mother tongue.. From my pov he wrote
>>> misleading statements about Melpa which did sound like gaslighting to me.
>>
>> Forgive me for guessing, but could your native language be German?  I'm
>> just inferring from the name.  If so, what did you want to say?
>> Vielleicht verstehe ich so besser was du meinst?
>
> Ja meine Muttersprache ist Deutsch, vielleicht geht es besser so.
> Ich habe es so verstanden das man Melpa nicht nennen sollte weil Melpa
> nicht kooperiert mit Gnu, was meiner Meinung nach nicht war ist
> bzw. mir neu wäre. 
>
> Beide Quellen enhalten die nicht freie Software verwenden (Melpa:
> Lastpass, Elpa Excange support).

Ich verstehe deinen Satzbau hier nicht, anstatt einem Objekt nach
"enthalten," fängt ein Untersatz an ", die nicht...".  Willst du sagen,
dass beide Archive nur Freie Software enthalten?

> Dadurch fällt mir als einziger Unterschied Github bzw. Forge basierte
> Entwicklung und Mailinglisten basiertes Model.
>
> OT: Ich spreche Deutsch selten in den letzten Tagen, habe generell
> manchmal Probleme mich auszudrücken es ist nicht nur das Englische, AHDS
> sei dank.

I'll translate this for the others on the list:

     My native language is German, so perhaps this is better.  I
     understood that one shouldn't mention MELPA because MELPA doesn't
     cooperate with GNU, which in my opinion isn't true or rather would
     be new to me.

MELPA ist ein eigenständiges Projekt welches seine eigenen Ziele hat,
welche nicht zu 100% mit dem GNU Projekt im Einklang stehen.  Es gibt
fundamentale Meinungsverschiedenheiten welche seit Jahren bestehen.

MELPA is an independent Projekt with their own Goals.  There aren't
100% aligned with those of the GNU Project.  There have been fundamental
differences of opinion that have existed for years.

     Both sources contain which don't use Free Software (MELPA:
     Lastpass, ELPA Exchange support) [this is a literal translation, I
     can't make sense of the sentence in German either].

     Thereby the only difference I can notice is GitHub, or rather a
     Forge-based development vs. a mailing list model.

Abgesehen von den technischen unterschieden, gibt es verschiedene
Guidelines zwischen den Projekten, welche Pakete angenommen werden.
Dahingegen sind die Fragen der Umsetzung (Mailing List vs PR-basierte
Webseite) recht nebensächlich.

Setting aside technical differences, there are different Guidelines what
packages are accepted.  Compared to that the question of how the
projects are organised (Mailing List vs PR-based Website) is not that
important.

GNU ELPA: https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/README#n330
MELPA: https://raw.githubusercontent.com/melpa/melpa/master/CONTRIBUTING.org

>>>>>                                                        You might not
>>>>> like to hear it but without Melpa Emacs wouldn't be were it is now..
>>>>
>>>> This is a counterfactual discussion, because it cannot be said if MELPA
>>>> was a necessary or contingent fact.  I agree that MELPA provided an
>>>> important service in collecting the number of packages that it did, but
>>>> if NonGNU ELPA had been created over 10 years ago with the regular GNU
>>>> ELPA, perhaps it would have been enough?
>>>
>>> Some have issues with the FSF, RMS etc. staying out of the whole thing
>>> was convenient for some.
>>> Even if you ignore that Melpa was more convinient to use unless there's
>>> a more modern way to interact to with ELPA.
>>
>> I have floated the idea of creating an Emacs package for submitting ELPA
>> packages, that would help automatise the repetitive questions, such as
>> have you signed the FSF CA if you want to add a package to GNU ELPA, are
>> all the dependencies available, has basic code style been respected that
>> checkdoc and byte compilation can detect, etc.  
>
> That sounds like a good idea, some kind of CI that checks the packages
> would be nice, the Ci can run on the creation of a request or on
> whitelist.

That can be difficult on a free-form mailing list like this one, unless
there is some formal indication (which is something a package like this
could provide).

> I think for a lot of people the way that the FSF acts or just the name
> leaves a bad taste in their mouth. Personally I think it quite sad that
> there isn't more corporation, I wish the FSF and FSFE would push for
> more free software in government and elsewhere around the world.
> In a lot environments uncertainty around free software especially after
> GPLv3 was released created by issues.
> A lot of places I've worked at had almost an allergy against things such
> as GPLv3.

I wish the entire GNU Project would be more integrated towards the
creation of a GNU Operating system, but that really is an off-topic
issue for this list.

>> Another idea I have heard been suggested is creating a separate issue
>> tracker for ELPA submissions and issues.  I am not sure if this would
>> help that much, but I guess some people avoid the mailing list because
>> they don't want to initiate a long discussion.
>
> If debbugs would be list a little modern such things would be easier,
> just create a bug at the Gnu bugtracker under the ELPA product. 

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.

>>>>>> A given package that happens to be in MELPA may be perfectly fine in
>>>>>> and of itself, or it may have problems of one kind of the other.
>>>>>>
>>>>>> If you come across a package in MELPA that has no particular problems,
>>>>>> we can DTRT to put it in either GNU ELPA or NonGNU ELPA.
>>>>>
>>>>> It's perfectly fine that is on Melpa, not everyone likes the mailing
>>>>> list based approach of Gnu.
>>>>> Offer other options such as a Gitlab or Gitea instance instead of
>>>>> antiquated Savanah (or make it more modern in other ways)
>>>>> and people might move elsewhere.
>>>>
>>>> I am afraid you have some misunderstandings regarding GNU ELPA (and I
>>>> suppose NonGNU ELPA as well).  GNU ELPA packages can and often are
>>>> developed on PR-based forges, where the state is synchronised into
>>>> elpa.git/nongnu.git, where the packages are build and distributed.
>>>> There is no need to use mailing lists -- except maybe to announce a
>>>> package and to request it be added to an archive.  But am I understating
>>>> your correctly that that is really the point you are objecting to?
>>>
>>> I'm sorry I wasn't aware of that, I assumed that using Github to develop
>>> the package is enough to disqualify it.
>>
>> No, that is the great thing about Git.  I can clone and hack on a
>> package that is hosted on GitHub, without ever having to accept the
>> execution on Non Free Javascript on my device.  Sure, the GNU project
>> would advise against using GitHub for several reasons, but as long as
>> you don't force others to use Non-Free Software, it is not a
>> deal-breaker.
>>
>> Just take a look at the current list of packages included in ELPA:
>>
>>   https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages
>>
>> There are plenty of packages that are developed on GitHub or GitLab.
>> Almost none are currently maintained on Savannah.  Luckily more and more
>> are also appearing on freedom respecting sites like Sourcehut.
>>
>> (I really don't know where this kind of misinformation stems from.  I
>> have heard it too, and was scared at first.  But it turns out that
>> people who haven't quite understand the arguments keep arguing against
>> strawmen in their own minds.)
>
> Yeah I understand that, I use Git in a similar way,  I have my own
> mirrors but use Gitlab/Github for the network effect in the communities
> I need it.
>
> But the misinformation came at least from my side out of the issue
> that I wasn't aware that Melpa contains packages that engages with
> non-free software at least not to the extend that Emacs already does.
> Like there are Windows build for macos and Windows, Melpa contains
> packages for that interact with such operating systems in the same way.

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.

> So Github was only remaining thing that is left as an issue.
> To be honest it makes sense since relaying it as a central hub is just
> bad no matter your position of free software..
>
>>> I am objecting against the assumption Melpa equals bad. I can understand
>>> the issue with some of it's packages or even the place of distribution
>>> but it hard to replace a platform like Github for the network effect it
>>> has.
>>
>> The issue was just that Emacs doesn't want to refer to MELPA, because
>> the two projects clash in their respective interests.  My understanding
>> is that MELPA tries to be exhaustive, while Emacs/ELPA prioritises that
>> all software can be used without loss of functionality on a fully free
>> system.  A choice has to be made.
>> IMO this is often the result of "bad" software choices.  The point is
>> not to ignore non-free software and pretend it doesn't exist.
>> Proprietary software is a means of exercising control over a user, and
>> some people are stuck in dominating environments, where the lack of
>> software freedom is symptomatic for their entire predicament, not
>> necessarily the cause of it.
>
> It is not just bad software choices but also idealism vs reality.
> I can try to change the predicament that I'm tied to some non free
> programs or system but at some point my means are exhausted.
> First I need to have the means to do it, for example: I'm a software
> engineer I try to find alternatives, setup my own systems if needed and
> find out what is the best tool for what I want to do.
> But a lot of people don't have that power either because they don't have
> the resources or their environment forces them.
> For example at work or because the government doesn't offer free
> alternatives.
>
> I respect people such as RMS for sacrificing the convenience of using
> only free systems but I think that doesn't work for most.
>
> So to be able to keep using free software their are some Emacs packages
> or programs that interface with non-free systems. Referencing Melpa for
> such packages seem It is not just bad software choices but also idealism vs reality.
> I can try to change the predicament that I'm tied to some non free
> programs or system but at some point my means are exhausted.
> First I need to have the means to do it, for example: I'm a software
> engineer I try to find alternatives, setup my own systems if needed and
> find out what is the best tool for what I want to do.
> But a lot of people don't have that power either because they don't have
> the resources or their environment forces them.
> For example at work or because the government doesn't offer free
> alternatives.
>
> I respect people such as RMS for sacrificing the convenience of using
> only free systems but I think that doesn't work for most.
>
> So to be able to keep using free software their are some Emacs packages
> or programs that interface with non-free systems. Referencing Melpa for
> such packages seem fine for me, except for instances where Elpa contains
> these packages themselves such as for Exchange support (Excorporate).
>
> That Emacs supports Windows, MacOS or other non-free platforms has a very
> similar reason I think.fine for me, except for instances where Elpa contains
> these packages themselves such as for Exchange support (Excorporate).
>
> That Emacs supports Windows, MacOS or other non-free platforms has a very
> similar reason I think.

This discussion should probably continue on emacs-tangents@gnu.org, if
you want to.

>> I always like the example of browse-url, which has a user option
>> `browse-url-browser-function'.  Among other things, you could set it to
>> the function `browse-url-chrome'.  But wait, isn't Chrome the famous
>> non-free browser that spies on its users and one day might even make
>> watching an advisement mandatory?  Sure, but all browse-url does it
>> provide a generic way of opening a URL in some external program.  If the
>> user has to use Chrome, that is bad, but they don't have much of a
>> choice.  But for free people, at home or in less restrictive
>> environments this doesn't make their "browse-url'ing" any worse.  Chrome
>> is a possible, but not a necessary way to implement the feature.  I
>> still get to use Firefox or eww.  So everyone is happy, because the
>> functionality is generic and not called something like
>> "browse-using-google-chrome-and-only-google-chrome" -- which wouldn't
>> even make sense in this context.
>
> Yeah it is kinda strange, like why don't use your operating system for
> such choices, no need to have a function for that.

You can do that too, in fact that is what the default implementation
`browse-url-default-browser' does.

>> The simple fact is that MELPA insists on distributing software that make
>> these mistakes instead of trying to find a compromise position that can
>> help people bound to non-free systems make the most out of Emacs, while
>> not placing the rest at a functional disadvantage.
>>
>> In my eyes this is more than reasonable.
>
> I think people should have the ability to choose what they want to use,
> so unless the package is malicious I see no issue with people using a
> package.
> Doesn't mean that I like it thou.

OK, that has always been possible, because you can add MELPA, and even
if MELPA went down, you could install it manually.  Nobody is inhibited
from installing and using non-free software, but the GNU project isn't
interested in helping them either.

> Thanks for talking Br,
>
> Björn