Re: Bugzilla: Reducing bugspam and finding patches

[Mark McLoughlin <markmc redhat com>]

On Wed, 2005-06-15 at 11:15 +0100, Bill Haneman wrote:
> >  
> >
> >>3. Already fixed (duplicate)
> >>   Some crashers have been fixed a long time ago, but they still receive
> >>   daily bugreports. These bugreports can now be rejected automatically.
> >>   For this the first 5 functions of the stacktrace are used, coupled
> >>   with the GNOME version (to prevent regressions being rejected).
> >>    
> >>
> >
> >	This one worries me a little - e.g. look at one of the panel crashers:
> >
> >150809 /GNOME2\.8\./ gtk_widget_set_sensitive g_cclosure_marshal_VOID__POINTER g_closure_invoke g_signal_has_handler_pending g_signal_emit_valist gnome-panel
> >
> 
> >...
> >Cheers,
> >Mark.
> >
> 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.

	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.

	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.

Cheers,
Mark.

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers