From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Why not include all ELPA packages in an Emacs release? Date: Thu, 30 May 2024 14:20:50 +0300 Message-ID: <86mso7r1f1.fsf@gnu.org> References: <87bk4ql3u5.fsf@jeremybryant.net> <864jagu9ji.fsf@gnu.org> <878qzspd9j.fsf@gnu.org> <87y17rag37.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tsdh@gnu.org, arash@gnu.org, stefankangas@gmail.com, jb@jeremybryant.net, emacs-devel@gnu.org, monnier@iro.umontreal.ca, philipk@posteo.net To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 30 13:24:46 2024 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 1sCdtk-0007Ty-Ih for ged-emacs-devel@m.gmane-mx.org; Thu, 30 May 2024 13:24:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCdq4-0000QJ-Cm; Thu, 30 May 2024 07:20:56 -0400 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 1sCdq3-0000Pq-2K for emacs-devel@gnu.org; Thu, 30 May 2024 07:20:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCdq2-0002F0-FP; Thu, 30 May 2024 07:20:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dwj9CimvAflDrOVoRRe9tdtPLz7yopNsDrKPXzv+lpY=; b=Nlm04wwFNXJu 0BDJus3Dr5QjXbZt3saizKaWkMdGvOCZtt2GBY5uG4UYe5khovw+yP/Z48I9SkDgty9JgUXAtQPHe bHFAAHKa2/AthBzuaRav9hu9iA8J50fFfYfNwWbJJnCob9mzk11bIBKTjiuFmF8OqUhiSdTyk0twc OljwU/QbWkbNyPGxNtzWLGOe/CWgSo4BuPbGJFKnReS1m6G3AbJ4ZXz3xOqS0KJAY9dv1mtXzjfdj bPY3cnkuH/XXXx3iVUl2q76ZawM9RhjBK4ISTzonbFg8pIVuzjkQ4dLf+zsgiFBvAaHCgXJ7iINkV xcFKZ0ryNzRtvkHx6L+8Ew==; In-Reply-To: <87y17rag37.fsf@yahoo.com> (message from Po Lu on Thu, 30 May 2024 15:55:56 +0800) 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:319741 Archived-At: > From: Po Lu > Cc: Arash Esbati , Eli Zaretskii , Stefan > Kangas , jb@jeremybryant.net, > emacs-devel@gnu.org, monnier@iro.umontreal.ca, philipk@posteo.net > Date: Thu, 30 May 2024 15:55:56 +0800 > > Tassilo Horn writes: > > > FWIW, I'd rather move more stuff from core to ELPA and add mechanics to > > install from ELPA easily. use-package was one such thing but I imagine > > a mechanism that would provide package suggestions, e.g., like asking a > > user to install toml-mode when finding a toml file for the first time, > > or suggesting to install calc or calculator when typing calc at the M-x > > prompt... > > Definitely not. calc-mode is one of those packages that are intimately > connected to functionality provided in core, and it would be a > tremendous inconvenience if Emacs developers were required to install > changes in more than one repository when the next core change with > far-reaching consequences, such as bignums had, comes along. Packages that will be moved to ELPA (when that happens) should have their dedicated maintainers, and it will be the job of those maintainers to adapt to any changes in Emacs that affect each package. I see no show-stoppers there, FWIW. > I think it is generally counterproductive to deny or impair our control > over the distribution and maintenance of packages, whether they be also > published on ELPA or not. As no one has suggested that the quantity of > code being maintained in the repository now has become an intolerable > burden, let us not invent imaginary problems and, with them, paralyzing > solutions. The issues which led us to seriously consider moving some core packages to ELPA are not imaginary, they are very real.