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

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

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.

>> That being said, if I had a single-use time machine I wouldn't waste it
>> on finding out insignificant something like this.
>>
>
> Nothing to argue about that.
>
>>>> 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.)

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

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.

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.