From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: Moving packages out of core to ELPA Date: Sat, 17 Feb 2024 21:14:06 -0500 Message-ID: References: <87h6i6y2ch.fsf@yahoo.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) 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="3826"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 18 03:15:03 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 1rbWhr-0000t1-ME for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Feb 2024 03:15:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rbWhE-000597-BP; Sat, 17 Feb 2024 21:14:24 -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 1rbWhB-00058t-FJ for emacs-devel@gnu.org; Sat, 17 Feb 2024 21:14:21 -0500 Original-Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rbWh9-0002G5-Sz for emacs-devel@gnu.org; Sat, 17 Feb 2024 21:14:21 -0500 Original-Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-7873eaa0ce7so91469285a.1 for ; Sat, 17 Feb 2024 18:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708222459; x=1708827259; darn=gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CG0oZMFPc++gJxReVKonYLBnsKPwX6cwb6Lk5b11tyM=; b=kE3nXHC/JprbSmxZzrhrOImf8YucqCo70+VbwPhm0xSJyxaOUkwecZPHaD00qhOs8Y CaS8mUDVpaYXs8nHgfIOGesywROkPMfnrMIep46JZjbqZqANc7lb/DWg9pjsyFII4osE A4weCqMMLssdKsf3zvA1tR+WRJLvTfe0Ho+Tn5IWDnFbMbYJn3aGPgAlWdcDj/3R8xi7 qA2ERqbLmONqav3EB9rzjQcrmgZ+qKSPb6ZS8Jfg34oxmy+rru7nyFwdJy1CXNy/ZlZH Uu4qUTEzcbe00Fvl3sSeB3PV1CCVTnXXM7cQcAmiUm+8operXTN8j6B8ijL+I4YvFtzp H/dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708222459; x=1708827259; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CG0oZMFPc++gJxReVKonYLBnsKPwX6cwb6Lk5b11tyM=; b=fE7v+KePICz9/dIlL9L7FQgx2AgfcH7IRp/wu4dnGFkn3oR17P2blOR3QA48TVjpmF NG/pW2csyjLAUqaNMmzdQRwq9YNfx4Eq8Z0tiO5NF0EwcsSQtBbVUf8grDmuVB4caki1 FCriCn4eTJ1a8YekFulz1S0jX5fW+5ITgFgirZxPQkr80laMS2EA/jpSdQgro2BZA0vc 2MALmOulrxXnaCLDWbB/Lg7TweDsPS86ztiNreUMePnLVFlkPO/Ygxfm8RzDqDd6kNko 9fhAW1VGCrH0I+F/8MOl72p5hzREM8j0ak8mHBa8EhAW7uGgkG9GKbGrX3AfecP8Ednl eC0Q== X-Gm-Message-State: AOJu0Yy+CvnT6pOcZJPn9zKhChSaC1pjpzuvKfFKf0+kF+/MOHTpkVrq lT/DFcRpnV8n+PKsI7QlNU52ninum7jEylso3yXxNcnV6NtYIYQ9CfMrZMcZ X-Google-Smtp-Source: AGHT+IHAqcml8yORFeAHGm/tb6P+h+guRO8/RCtlcgdVAhfj3nfTWZNeSvFsjYdJtUFcLQ8z5jTbCw== X-Received: by 2002:a0c:f288:0:b0:68c:8f4d:c754 with SMTP id k8-20020a0cf288000000b0068c8f4dc754mr8839622qvl.4.1708222458717; Sat, 17 Feb 2024 18:14:18 -0800 (PST) Original-Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id lb6-20020a056214318600b0068f1237f904sm1631349qvb.77.2024.02.17.18.14.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Feb 2024 18:14:18 -0800 (PST) In-Reply-To: <87h6i6y2ch.fsf@yahoo.com> X-Mailer: Apple Mail (2.3774.300.61.1.2) Received-SPF: pass client-ip=2607:f8b0:4864:20::730; envelope-from=jdtsmith@gmail.com; helo=mail-qk1-x730.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:316290 Archived-At: > On Feb 17, 2024, at 8:42=E2=80=AFPM, Po Lu wrote: >=20 > JD Smith writes: >=20 >> There was a recent discussion about which lisp/progmodes packages >> belong in core. A sentiment was expressed that useful languages with >> non-negligible user bases should probably go in, and others should be >> in ELPA. >>=20 >> I want to bring up a related point: it should be possible to retire >> packages from core, once their relevance drops below a critical >> threshold [1]. >=20 > Every instance of this is a mistake. =20 That would imply that every instance of bringing a package into core is = not a mistake, which suggests superhuman forecasting and = decision-making. But even when including a package is beneficial, = situations change over time (>20 yrs, in this case). It seems only = prudent to reevaluate whether a given package still provides sufficient = benefit given the non-zero costs associated with it. > Why is it so essential that such > packages be removed from core? What practical advantage does that = hold? Many which I mentioned in my initial message. The most salient: - Reduces maintenance burdens, freeing time for packages that have more = pressing issues. I have heard from emacs maintainers who have spent = significant time trying to understand and fix bugs in IDLWAVE code that = is likely unused (even by me). - Removes "tripping hazards" for users who inadvertently activate the = mode for unrelated files and are confused (this is not hypothetical: = I've had numerous reports). - Cuts down on "extra noise" in, e.g., the top level Info help. > A Lisp file is considered part of Emacs, whether it be in core or in > ELPA. They are expected to meet like standards, and bugs (in the > absence of a maintainer) are the responsibility of the same Emacs > developers who respond to bugs that concern Emacs in general, i.e., = like > developers. =20 Is this really so, in practice? I have packages in ELPA which are = effectively untouched except by me, other than on first ingestion. And = they draw updates from a repo I maintain myself. Maybe I've = misconstrued the situation, but my understanding has been that core = packages receive far more attention from maintainers. And rightly so, = IMO: everyone has them installed, after all. =20 Also, if ELPA and core are truly equivalent, I cannot then understand = the common strategy of "let it mature on ELPA for a few years, then = potentially migrate to core." >> It deserves support in Emacs. Just not, IMO, in core. >=20 > Why not? Why does _anything_, to speak nothing of a package already = in > core, not "deserve" support in core, while deserving support in ELPA? Because in ELPA, users must proactively opt-in to the use of the = package. For such users =E2=80=94 those who have actively sought it out = =E2=80=94 in stark contrast to the vast majority of Emacs users, the = benefits dramatically outweigh the costs.=