From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Hyatt Newsgroups: gmane.emacs.bugs Subject: bug#1452: Acknowledgement (23.0.60; Problem with nextstep, longlines-mode,) Date: Wed, 06 Jan 2016 22:54:30 -0500 Message-ID: References: <20081129.145347.35808910.hanche@math.ntnu.no> <20081129.155222.124907962.hanche@math.ntnu.no> <20081129.161126.71259916.hanche@math.ntnu.no> <5vy4c46ifr.fsf@fencepost.gnu.org> <83oacz5188.fsf@gnu.org> <83y4c32wwf.fsf@gnu.org> <83k2nm2gyi.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1452138923 16546 80.91.229.3 (7 Jan 2016 03:55:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jan 2016 03:55:23 +0000 (UTC) Cc: hanche@math.ntnu.no, jwiegley@gmail.com, 1452@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 07 04:55:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1aH1fL-0003MN-HY for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jan 2016 04:55:11 +0100 Original-Received: from localhost ([::1]:56762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aH1fK-0007mE-Lp for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jan 2016 22:55:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aH1fG-0007k8-3F for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 22:55:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aH1fC-0000wg-Qe for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 22:55:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aH1fC-0000wG-Mt for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 22:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aH1fC-0004wF-FJ for bug-gnu-emacs@gnu.org; Wed, 06 Jan 2016 22:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrew Hyatt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Jan 2016 03:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 1452 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 1452-submit@debbugs.gnu.org id=B1452.145213888118953 (code B ref 1452); Thu, 07 Jan 2016 03:55:02 +0000 Original-Received: (at 1452) by debbugs.gnu.org; 7 Jan 2016 03:54:41 +0000 Original-Received: from localhost ([127.0.0.1]:40732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aH1eq-0004vd-TP for submit@debbugs.gnu.org; Wed, 06 Jan 2016 22:54:41 -0500 Original-Received: from mail-qk0-f180.google.com ([209.85.220.180]:35999) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aH1ep-0004vR-H1 for 1452@debbugs.gnu.org; Wed, 06 Jan 2016 22:54:39 -0500 Original-Received: by mail-qk0-f180.google.com with SMTP id q19so115649922qke.3 for <1452@debbugs.gnu.org>; Wed, 06 Jan 2016 19:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=wklWZ7LqNxl/1N6eXPMYhcxnaQAY/wVC8DnqGWNuTWk=; b=F4zyVEX2+kVHOjYNvS5J36IXkKebD4eUBpGcdhcIF5rPu0QA7+jDht9ipYTfui+2PC 02Iwgagdl9TekYIEE6O8Lkk2ZAiRKytrHA92gJqXEwcHxhd+KsCwpxA5mGbW+Vs0kaOZ 7B9Iw6JfSAqxPi3xGQ+IYtx0uIkxS+xy1Al3Adx7NHAbzYwhxCBo90LyJgECD6TOnXqD Ygto3S0AEiwuM/ayECq3gH1fRaEBZfEWSeKD1uR8v70xeO4fO9NwxPII+YIzVENVZjys qmjl4i+eqq6whHQ5lUPje/XfZvJFo4i731nLGEdq59pPMmML9rcK0H8P6Ls+BSL4hrzT MbWQ== X-Received: by 10.55.76.11 with SMTP id z11mr133263195qka.83.1452138873881; Wed, 06 Jan 2016 19:54:33 -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 n35sm22990794qgn.10.2016.01.06.19.54.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2016 19:54:32 -0800 (PST) In-Reply-To: <83k2nm2gyi.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 07 Jan 2016 05:42:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:111313 Archived-At: Eli Zaretskii writes: >> From: Andrew Hyatt >> Date: Thu, 07 Jan 2016 01:42:58 +0000 >> Cc: jwiegley@gmail.com, rgm@gnu.org, hanche@math.ntnu.no, 1452@debbugs.gnu.org >> >> what I'm mostly trying to figure out is if there is *any* way to get >> code to be completely unmaintained. > > I think removing it is the only way. Yeah, I guess that's what I suspected. It seems reasonable, as long as we can remove things. > >> We are, after all, trying to reduce the number of bugs (see the >> thread on 4k bugs) overall, and this is one way to do that. So the >> only way people would agree on right now, is if we remove the code >> entirely from emacs distribution. But I suspect that such a change >> would be rejected, even from obsolete packages, because someone >> might still be depending on them. > > It depends on how long the package was obsolete, I guess. > > We could define a policy, like a package is deleted after so-and-so > many months/years in obsolete/. If you think such a policy would be possible, then I'm happy to propose it in emacs-devel. Maybe obsolete packages can spend one major version in obsolete, and get deleted in the next major version? Or, maybe we can be more aggressive, especially if you think that we can do this over periods of months, and obsolete and deprecate based on minor version instead.