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