Re: Subject: Re: Stock response addition

[Fernando Herrera <fherrera onirica com>]

El mar, 23-11-2004 a las 12:12 -0700, Elijah Newren escribi�
> Since bug-buddy can now find executables in $PREFIX/libexec, the only
> thing that I can think of that could really be done to improve what
> bug-buddy could find would be to make sure distros ship with debuginfo
> packages installed by default, or compiled with debugging information
> left in.  Or at very least not strip them.  But that isn't going to
> happen.  Doing that makes binaries bigger and slower (slower mainly
> because they're bigger and memory requirements are already large
> enough...)
> 

	One thing we can "easily" do is to check if the binary crahsing and
related libs are compiled/installed with debug symbols. If no we can do
some stuff:
	A) Just warn the user that that info would not be very helpful

	b) Warn the user about that and if he is running a distro with know
-debuginfo packages, suggest to install them
		b.1) If we had a gnome-system-packages, use it to intall it :).
Volunteers?

	c) Accept the bug report if it comes from a known vendor (Red Hat,
SuSE, etc... so they are standard packages) and do the backtracing
offline on an special server donated by ... volunteers?
 


> > I realise usability bugs have issues, such as being ver difficult to
> > demonstrate a solution. But I guess there's a metric here in how many
> > non-useful bug-buddy generated reports are bein recieved vs useful
> > bug-buddy generated reports.

	For me having tons of dups of the same bug without an useful backtrace
is a good metric in the sense of "man, gconf-editor is crashing every
time on FC2test3, what's the hell?"

Salu2