From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: "Andrew W. Nosenko" <andrew.w.nosenko@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
Tassilo Horn <tassilo@member.fsf.org>,
emacs-devel@gnu.org
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 [thread overview]
Message-ID: <87zkt6bil0.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <AANLkTi=tO6Fj51hWfZ+zCr7UEtr48UM21tgJQvWP2vdy@mail.gmail.com>
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.
next prev parent reply other threads:[~2010-11-18 18:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 10:59 bug#7419: 24.0.50; emacs -Q -nw positions cursor in empty lines on the second column Gregor Zattler
2010-11-17 12:17 ` Eli Zaretskii
2010-11-17 16:35 ` Gregor Zattler
2010-11-17 19:28 ` Eli Zaretskii
2010-11-17 19:41 ` Glenn Morris
2010-11-18 7:48 ` 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) Tassilo Horn
2010-11-18 8:19 ` Searching bugs before filing new ones Glenn Morris
2010-11-18 10:14 ` 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) Eli Zaretskii
2010-11-18 16:40 ` Andrew W. Nosenko
2010-11-18 18:19 ` Stephen J. Turnbull [this message]
2010-11-18 21:22 ` Searching bugs before filing new ones Glenn Morris
2010-11-18 22:20 ` Stefan Monnier
2010-11-19 11:51 ` tomas
2010-11-19 20:29 ` Glenn Morris
2010-11-21 20:10 ` tomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zkt6bil0.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=andrew.w.nosenko@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=tassilo@member.fsf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.