From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Searching bugs before filing new ones (was: Re: bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column) Date: Fri, 19 Nov 2010 03:19:23 +0900 Message-ID: <87zkt6bil0.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20101117105947.GB21042@shi.workgroup> <8362vvda2j.fsf@gnu.org> <201011180848.18858.tassilo@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1290104314 17383 80.91.229.12 (18 Nov 2010 18:18:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 18 Nov 2010 18:18:34 +0000 (UTC) Cc: Eli Zaretskii , Tassilo Horn , emacs-devel@gnu.org To: "Andrew W. Nosenko" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 18 19:18:29 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ93w-0002jW-8O for ged-emacs-devel@m.gmane.org; Thu, 18 Nov 2010 19:18:24 +0100 Original-Received: from localhost ([127.0.0.1]:53991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJ93v-00020x-JK for ged-emacs-devel@m.gmane.org; Thu, 18 Nov 2010 13:18:23 -0500 Original-Received: from [140.186.70.92] (port=55202 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJ93q-0001zz-0z for emacs-devel@gnu.org; Thu, 18 Nov 2010 13:18:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PJ93o-0006Ym-Aw for emacs-devel@gnu.org; Thu, 18 Nov 2010 13:18:17 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:55681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PJ93l-0006YG-TE; Thu, 18 Nov 2010 13:18:14 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id D99AE2AF543; Fri, 19 Nov 2010 03:18:10 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id C90A32AF542; Fri, 19 Nov 2010 03:18:10 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id C3E4D3FA0522; Fri, 19 Nov 2010 03:18:10 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 09D5C1A3EF2; Fri, 19 Nov 2010 03:19:23 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132821 Archived-At: Andrew W. Nosenko writes: > Usually, in general case, an user that reports a bug has not enough > skills and knowledge in the area for be sure that a bug, which he > going to report, and a bug, which found by pre-submit query, are > duplicates indeed. Therefore, request he to make such decition is > just unfair (and ineffective). The point is not to group exact dupes with extreme accuracy. The point is to group similar bugs so they get worked on at the same time in hopes they are the same bug. If there are actually several bugs, then some don't get fixed, the users say "hey, you say it's fixed but it's not!", and the remaining bugs get fixed. With some luck, they'll even be bugs "near" the one that got fixed and the developer will have an easier time fixing them since the code is fresh in his mind. If the bugs are not grouped, then the the users who report dupes probably will *not* receive notice that their bugs are fixed. If in fact their bugs are dupes, they may wait longer to try a new version (always risky for the non-tech user). That's bad. Also, if the bugs are the same, but the developer looks at them at different points in time, it may take longer and be more annoying for the developer to triage them and properly label them as dupes. I conclude that in dupe detection, false positives are not as big a problem as false negatives. The problem is to communicate to the users that good guesses are good enough; don't be shy.