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)

[Stephen J. Turnbull]

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.