Re: feature/package-vc has been merged

["Björn Bidar" <bjorn.bidar@thaodan.de>]

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

Ja genau, beide Quellen enthalten nur freie Software. Beide Quellen
haben aber Software die mit nicht freier Software interagiert.

I translate this my self: Yes both sources contain only free software,
but both contain software that interacts with non-free software.

Anyway you don't have to write in German just for me, it's fine.

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

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.

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


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.

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

Ok

Br,

Björn