From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: CHENG Gao Newsgroups: gmane.emacs.devel Subject: Re: Basic questions about the triage process Date: Tue, 29 Dec 2015 14:46:48 +0800 Organization: Royau.Me 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 X-Trace: ger.gmane.org 1451371660 19530 80.91.229.3 (29 Dec 2015 06:47:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2015 06:47:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 07:47:32 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 1aDo4A-0002V1-LP for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 07:47:30 +0100 Original-Received: from localhost ([::1]:47241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDo49-0006ea-Rj for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 01:47:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDo3m-0006eJ-SE for emacs-devel@gnu.org; Tue, 29 Dec 2015 01:47:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDo3h-0008SN-Rj for emacs-devel@gnu.org; Tue, 29 Dec 2015 01:47:06 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:33245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDo3h-0008RP-LD for emacs-devel@gnu.org; Tue, 29 Dec 2015 01:47:01 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aDo3f-00020J-2t for emacs-devel@gnu.org; Tue, 29 Dec 2015 07:46:59 +0100 Original-Received: from 112.80.134.5 ([112.80.134.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2015 07:46:59 +0100 Original-Received: from chenggao by 112.80.134.5 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2015 07:46:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 50 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 112.80.134.5 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin) Cancel-Lock: sha1:UgiIj+NVNorSNMGPpQqq5J4405g= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:197064 Archived-At: *On Mon, 28 Dec 2015 17:21:22 -0800 * Also sprach John Wiegley : >>>>>> Lars Ingebrigtsen writes: > >> Andrew Hyatt writes: >>> That sounds like a good idea for bugs of reasonable recentness. I'm >>> going through old bugs that are years old now. To me, it feels a >>> bit awkward to suddenly ask people to confirm anything after years >>> have passed - just closing seems like a more reasonable approach to >>> me. But I'll follow your advice for bugs in the last year. If you >>> feel strongly that time elapsed shouldn't matter, though, I'm happy >>> to do it your way all the time. > >> Yeah, if they're really old and aren't reproducing, closing them may >> be the right thing to do. > > 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 something From 2013 or earlier, close it as cannot reproduce > with a CC to the original reporter. Otherwise, ping the submitter with > a CC to the bug address saying it can't be reproduced, but leave it > open. Maybe the strategy needs a clarification of version supporting policy or should be based on said policy if it exists. Say for example 24.x line supported while 23.x support dropped. The priority could be as below: Number one: emacs-25 branch related Should have highest priority since they'll block the release. Number two: emacs git They slow down moving train. Number three: emacs 24.x Maybe a policy to include accumulated fixes in a new release untill support dropped, for example yearly bugfix on Dec. 25 or Dec. 31. Bug fixes only, no new feature backports. Number four: emacs 23.x/22.x etc (justing kidding. No kidding?) If bothered by "cannot sleep thinking users are abandoned in darkness" syndrome, accept users submitted patches and release accumulated bugfix minor version each year as above. Maybe a cycling poicy can be built. Just my RMB2 cents.