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: Moving packages out of core to ELPA Date: Sat, 17 Feb 2024 19:29:22 +0200 Message-ID: <865xynt2x9.fsf@gnu.org> References: <86jzn3t7gj.fsf@gnu.org> <095EDE5B-128C-4110-805B-EE218DB9F79A@gmail.com> <86bk8ft4o6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20879"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: JD Smith Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 17 18:30:19 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 1rbOW3-0005BD-68 for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Feb 2024 18:30:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rbOVH-0000nL-RJ; Sat, 17 Feb 2024 12:29:31 -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 1rbOVG-0000md-SP for emacs-devel@gnu.org; Sat, 17 Feb 2024 12:29:30 -0500 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 1rbOVG-0001RC-6z; Sat, 17 Feb 2024 12:29:30 -0500 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=wwioH9XBkiKxHUfLDc296UNgrHZG1gdg433GB9AGLx4=; b=bGhbp4B10eYe BtdzNVmkp35XEZbd5v9A6GkUr2aBE0z7LLJv+72y8G0if7zdb7aecBzq+7WNdNH+f19PIotqtxvg1 NIk03wKoQuNjcr8fnGZieNUV5XvrifWkQG5UzA69DlrHYqGENyRf04sf6L7WtFD61oaIw0jTrmTBr GdCuETPS9+KrzQ7rK36KpUYW8zW4aXSCxquHDUFJbyVO+e5FRq6YLlSKjl8y8ULual+VKxnyzALVI GSXFJbD1zTil8r/E9y8e3okvtX1foMfOaY+G7eEql6ewRDRuB/Q3gnJdsdR/YYKzizN0VRVRvNPVZ IH9B2gmlhSRanPa8ndaYBQ==; In-Reply-To: (message from JD Smith on Sat, 17 Feb 2024 12:08:37 -0500) 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:316271 Archived-At: > From: JD Smith > Date: Sat, 17 Feb 2024 12:08:37 -0500 > Cc: emacs-devel > > >>> We usually first retire such packages to lisp/obsolete/. There, they > >>> are still available, but need to be loaded manually. Moving something > >>> directly to ELPA might be too drastic, assuming someone somewhere > >>> still want to use it. > >> > >> Does that reduce the maintenance burden, for example because code in lisp/obsolete does not receive updates to documentation, stylistic code changes, etc.? Do you typically also remove the associated entry in auto-mode-alist when obsoleting in this fashion? > > > > Yes, I think so (on both counts). > > OK, then I suppose staging in lisp/obsolete/ makes sense. I do worry about the connotations of obsolete meaning "stop using", "does not work at all" or "soon to vanish". In fact IDLWAVE does still work and is useful for a small set of users, it just does more harm than good in core, IMO. We also call out the obsolescence in NEWS, so users will know, when the package fails to load automatically. > One idea would be to create another category for packages "on their way out" of core. I'm sure there's a better name, but lisp/noncore comes to mind. The intended difference being that obsolete packages will likely disappear entirely from the project, whereas "noncore" packages will be migrated to ELPA, where users can find them once they have left core for good. We don't yet have examples of such packages, I think. And in this case, we intend to move IDLWAVE out precisely because it is obsolete, so we don't need to consider a new category for this case, I think.