From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Basic questions about the triage process Date: Mon, 28 Dec 2015 17:50:05 -0800 (PST) Message-ID: References: <87lh8eoz7g.fsf@gnus.org> <87d1tqoye5.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1451353846 6799 80.91.229.3 (29 Dec 2015 01:50:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2015 01:50:46 +0000 (UTC) Cc: Xue Fuqiao , Andrew Hyatt , emacs-devel@gnu.org To: John Wiegley , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 02:50:30 2015 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 1aDjQj-0000AC-VJ for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 02:50:30 +0100 Original-Received: from localhost ([::1]:46821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDjQj-0004l1-Ci for ged-emacs-devel@m.gmane.org; Mon, 28 Dec 2015 20:50:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40719) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDjQW-0004kt-E1 for emacs-devel@gnu.org; Mon, 28 Dec 2015 20:50:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDjQT-00024a-79 for emacs-devel@gnu.org; Mon, 28 Dec 2015 20:50:16 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDjQT-00024W-0R for emacs-devel@gnu.org; Mon, 28 Dec 2015 20:50:13 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBT1o7HV024795 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Dec 2015 01:50:07 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tBT1o6cB018912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Dec 2015 01:50:06 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tBT1o6cO006739; Tue, 29 Dec 2015 01:50:06 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:197055 Archived-At: > > Yeah, if they're really old and aren't reproducing, closing them may be > > the right thing to do. >=20 > Andrew, I think your strategy is good, but can we turn that clock back to > two years? Emacs doesn't move all that rapidly. If you can't reproduce so= mething > From 2013 or earlier, close it as cannot reproduce with a CC to the origi= nal > reporter. Otherwise, ping the submitter with a CC to the bug address sayi= ng > it can't be reproduced, but leave it open. FWIW, I disagree that there should be a 2-year limit, or any limit. If Emacs Dev has never responded to a bug report, no matter how old, then it should be treated as new. If you cannot seem to reproduce it now then start by asking for more info - and not after closing it, just as you would do for a bug reported yesterday. If Emac Dev has responded previously, that's a different story. But there is a giant backlog of bugs, and some of them are several years old (perhaps even many years old) and have never been responded to. What should count, if you must count time elapsed, is the time since the last attempt by a bug fixer to obtain info. If no one has ever tried, then the clock should be reset to zero. (Just one opinion.)