From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Hyatt Newsgroups: gmane.emacs.devel Subject: A proposal for removing obsolete packages Date: Sun, 10 Jan 2016 22:09:27 -0500 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1452481797 25308 80.91.229.3 (11 Jan 2016 03:09:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Jan 2016 03:09:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 11 04:09:50 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aISre-0002hB-01 for ged-emacs-devel@m.gmane.org; Mon, 11 Jan 2016 04:09:50 +0100 Original-Received: from localhost ([::1]:50994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aISrd-000310-Dk for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 22:09:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aISrP-00030a-LQ for emacs-devel@gnu.org; Sun, 10 Jan 2016 22:09:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aISrM-00013p-EC for emacs-devel@gnu.org; Sun, 10 Jan 2016 22:09:35 -0500 Original-Received: from mail-qk0-x22d.google.com ([2607:f8b0:400d:c09::22d]:32785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aISrM-00013h-9G for emacs-devel@gnu.org; Sun, 10 Jan 2016 22:09:32 -0500 Original-Received: by mail-qk0-x22d.google.com with SMTP id p186so141712189qke.0 for ; Sun, 10 Jan 2016 19:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; bh=3B05z0g8KgKVWBIQMTetDClDP25B/uqtCn8Ak2N+7NM=; b=cCinsJjA7k8TFCrWfGRbotgcH/vB92mHMX+mNLs4XQlHTD7rfz3Hke+IOWExCGbKP8 81XGajSbmKzv7rSIvhfoZbGZ7fmgTVnUsBewAfm2uKxXGIRSrnznbB5SwIcT53gK6q46 PRaCsIE6t+7YXDPPToS5GXhO1JTI1yxHONoVRPMIYIQXoOIDX/i4T8BWL+/XRNzV61HU 5Qxp4WSH3T0T4mpui2GEmF+w/i48Ij8hav27H/ksSmrTBgTwsfRjcaqWJjmpIxRBdtO0 lwVEV2Y7s4JYstJUU2Ely3givMt2t+ap2T6aiEFGao6Q/FXleSUR/n+vIrQgMJBi8Wlu XecA== X-Received: by 10.55.76.84 with SMTP id z81mr69434055qka.17.1452481770488; Sun, 10 Jan 2016 19:09:30 -0800 (PST) Original-Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id f5sm1085478qkb.30.2016.01.10.19.09.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jan 2016 19:09:29 -0800 (PST) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198007 Archived-At: I'd like to propose a policy for feature removal - I'll just start out with the policy, and then give the rationalization, and discuss alternatives. Currently, obsolete elisp is moved to the obsolete subdir. Attempts to load them are successful, but come with the warning message " is obsolete!" I propose that we leave them in the obsolete subdir for one major version. At the start of every new major version, we remove everything from that subdir package that has been there since the start of last major version. For example, a package that is declared obsolete during the development of Emacs 25 would be moved to obsolete, and a message would be added to say that " is obsolete and will be removed in Emacs 27". It couldn't be removed in Emacs 26 because it didn't start Emacs 25 in obsolete. In short, obsolete package added in the middle of a release will be guaranteed to exist until the next major release, and then one more major release. The need for a policy arose while discussing with Eli and others what should be done with a bug against the obsolete longlines-mode (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=1452). We have many bugs, and it was a bit worrying that there was no way to remove a bug even against functionality that was obsolete. Plus, there was no accepted way to get anything out of obsolete. Where was the benefit, then, of putting things in obsolete at all? To me, it's clear that emacs would be well served by shedding some little-used functionality. The amount of elisp is enormous, and it mostly modifies a common user experience, so that each package can potentially create problems for each other package. By removing the obsolete packages, we can reduce the amount of potential issues. What if someone relied on an obsolete package? Mostly, like longlines-mode, better solutions have come along. Giving people an entire major version to switch seems pretty reasonable to me. For most obsolete functionality, we're talking years of existence in the obsolete subdir. If not, anyone still interested can create an ELPA package that they maintain on their favorite ELPA server - but not in gnu ELPA. There might be even better solutions to this problem. I certainly have not attempted to explore the entire space of solutions. Perhaps the timing is too long as well - I wouldn't mind making things more aggressive and instead removing all obsolete packages at the start of each major version (meaning that an obsolete package would last one major version or less). This probably would work itself out and obsolete packages would tend to not be removed at the end of the major version development cycle. Please let me know what you think.