From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: feature/package-vc has been merged Date: Sat, 12 Nov 2022 13:40:01 +0000 Message-ID: <87cz9sz3ym.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <831qqg1306.fsf@gnu.org> <874jvcowzm.fsf@posteo.net> <83y1soypvx.fsf@gnu.org> <87y1song5x.fsf@posteo.net> <83v8nsyof7.fsf@gnu.org> <87leoond7l.fsf@posteo.net> <87pmdxgptl.fsf@posteo.net> <87iljotycc.fsf@thaodan.de> <87k044fvx9.fsf@posteo.net> <87a650twv7.fsf@thaodan.de> <87wn84ednr.fsf@posteo.net> <87y1sks82p.fsf@thaodan.de> <87mt909g3o.fsf@posteo.net> <87leojswzm.fsf@thaodan.de> <875yfluy99.fsf@thaodan.de> <875yfk1uqm.fsf@posteo.net> <87y1sg5ntn.fsf@thaodan.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36261"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , stefankangas@gmail.com, monnier@iro.umontreal.ca, eliz@gnu.org, emacs-devel@gnu.org To: =?utf-8?Q?Bj=C3=B6rn?= Bidar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 12 14:41:07 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1otqkt-0009Dm-5M for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Nov 2022 14:41:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1otqk2-0000yD-85; Sat, 12 Nov 2022 08:40:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1otqk0-0000xw-00 for emacs-devel@gnu.org; Sat, 12 Nov 2022 08:40:12 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1otqjx-0003DW-KL for emacs-devel@gnu.org; Sat, 12 Nov 2022 08:40:11 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A2521240101 for ; Sat, 12 Nov 2022 14:40:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668260407; bh=EVmaFXRsMhtxA6zZzvY1ybMfHqCWtc+GL1ndo+ofAL0=; h=From:To:Cc:Subject:Date:From; b=Rlur7ojDAE3uMRkBQrFzVQMUV2JR3aXcuR/ZYJbf+8+qc/lS/BdTKVoBdXVTB8Avw 6lpo82XYRDFBDMXLZ3LmslYkcMJEk7m1vlKxDRxO6xmtutEWujPjfN9IamQzJvYB+b TELj7p++FWz313ADYPo5K6UcVaAf4LI9zqiRQVkR1ruF4ApbBMMyfCckhta3NBHTiq tweevd4c63yd541jf3A5IqOU1Xm/WGoRJPuTDsTQS/e3HAVifSUD3VKpdhv55h5nbH 1UQMCMCME9YdAoBC0bgUliaos20hOYgLRxzxwxrtF9xaSPvdcMokykSC69Eb5ImyvT uV1L4s4laTLKw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N8cBt4TlJz9rxF; Sat, 12 Nov 2022 14:40:06 +0100 (CET) In-Reply-To: <87y1sg5ntn.fsf@thaodan.de> (=?utf-8?Q?=22Bj=C3=B6rn?= Bidar"'s message of "Sat, 12 Nov 2022 15:01:24 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299650 Archived-At: Bj=C3=B6rn Bidar writes: > Philip Kaludercic writes: > >> Bj=C3=B6rn Bidar writes: >> >>> Richard Stallman 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?=20 >> >> 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.=20=20 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.