From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: How does the Emacs bug tracker work? Date: Thu, 30 Jun 2011 22:25:26 -0400 Message-ID: References: <4E0C44A2.1040604@dogan.se> <874o37tqq2.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1309487149 6473 80.91.229.12 (1 Jul 2011 02:25:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Jul 2011 02:25:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 04:25:45 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QcTQP-0004oB-5c for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2011 04:25:45 +0200 Original-Received: from localhost ([::1]:58489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcTQO-0000ZE-Dd for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2011 22:25:44 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcTQ9-0000Z0-QK for emacs-devel@gnu.org; Thu, 30 Jun 2011 22:25:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcTQ8-0000wE-JD for emacs-devel@gnu.org; Thu, 30 Jun 2011 22:25:29 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:41235 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcTQ8-0000vm-8X for emacs-devel@gnu.org; Thu, 30 Jun 2011 22:25:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscIAO0uDU5MCqDH/2dsb2JhbABSmG2Ob3iIeb9yhjIEnlGEKw X-IronPort-AV: E=Sophos;i="4.65,455,1304308800"; d="scan'208";a="118264812" Original-Received: from 76-10-160-199.dsl.teksavvy.com (HELO pastel.home) ([76.10.160.199]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 30 Jun 2011 22:25:26 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 967415912D; Thu, 30 Jun 2011 22:25:26 -0400 (EDT) In-Reply-To: (Lars Magne Ingebrigtsen's message of "Thu, 30 Jun 2011 23:22:59 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 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:141307 Archived-At: > So "closed" is mainly a way to say "I probably don't normally want to > have these included in my searches". So moving three year old > "wontfix"-es over to "closed" means taking less time searching for the > bugs you want to look at. No, in my experience what I want to include in my searches depends a lot on what I'm doing. If I'm searching for duplicates, I want to include pretty much all previous bugs no matter what, and if I'm looking for "bugs that need love" I don't want to include any wontfix, regardless of their age. IOW, I don't find the notion of "closed" to be useful. >> The bad ones are "untriaged", "forgotten" and "ready", so we should come >> up with a way to distinguish inprogress from untriaged, as well as a way >> to mark the forgotten ones as well, so we can ask debbugs to show us >> these ones. > If `date' is the same as `log-modified', it means that nobody has > responded to the bug. This can't be searched for, but can be > highlighted in the debbugs buffer. Rather than highlight, I'd like to see them sorted first, but yes, that should be good enough. >> I guess we could add "inprogress" and "forgotten" tags and then try to >> be careful to add "inprogress" whenever we first reply to a bug report. >> Then have some cron job check all the "inprogress" bugs and turn them >> into "forgotten" after some pre-defined delay (at which point humans >> way come and relabel it to "moreinfo" if the delay is not our fault). > Adding these tags aren't really necessary if using the debbugs.el > interface. An "inprogress" report is one that has gotten at least one > reply lately, OK. > and "forgotten" would be one where the reply is old. OK (except if it's marked "moreinfo", of course). > So this can be controlled client-side. If you don't consider 30 seconds > being too slow to get the complete list of bugs over to Emacs. Sounds fine, Stefan