Re: Bugzilla: Reducing bugspam and finding patches

[Olav Vitters <olav bkor dhs org>]

On Wed, Jun 15, 2005 at 11:29:55AM +0100, Mark McLoughlin wrote:
> On Wed, 2005-06-15 at 11:15 +0100, Bill Haneman wrote:
[..]
> > I suspect this heuristic would fail for a number of at-spi/accessibility 
> > bugs as well, since the stack frames (especially in non-debug builds) 
> > can look the same for quite different root causes, if things go haywire 
> > in a CORBA call.
> 
> 	Well, in that case we just wouldn't use this thing for at-spi bugs -
> i.e. not add at-spi bugs to the configuration.

Indeed, do not add them if they aren't specific to a bug. If having > 5
function would allow these to be detected I can try to implement that.

> 	That brings up another point actually - it might be a good idea for
> bugsquad people to consult with the maintainer before adding bugs to the
> configuration. Maintainers should be able to sport stack traces which
> could match other bugs.

We will of course do that if unsure. I created it mainly for bugs that
receive lots and lots of duplicates (like 153888); not for the general
case (although it can be used for that).

> 	All I'm saying really is that there's a tiny chance of this thing going
> wrong for a certain bug and if it rejects bugs rather than allowing them
> into the database and marking them as a duplicate, we'll not have a
> chance to ever actually see it going wrong.

You will really check to see if it correctly duplicated a bug each and
every time? I do have other things I want to implement and those will
not reject the bug, but resolve it right away. However, I see no point
in duping bug like 153888 forever and ever. The code is well tested
(retrieving the functions is taken from the simple-dup-finder) and I
will perform regular checks to ensure it works correctly (as I receive
all of the bug-buddy messages).

-- 
Regards,
Olav