Re: Stock response addition

[stappers stappers nl (Geert Stappers)]

On Tue, Nov 23, 2004 at 09:24:26PM +0100, Fernando Herrera wrote:
> 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
This the second best option.
It becomes better when it tells why and to do to make it usefull.

> 
> 	b) Warn the user about that and if he is running a distro with know
> -debuginfo packages, suggest to install them
This the one I prefer.
It helps with what is purpose in option a.

> 		b.1) If we had a gnome-system-packages, use it to intall it :).
> Volunteers?
Mmm, I missed almost the smiley.
(otherwise: <capslock>
   bugbuddy is bugreport, _not_ a package installer!
</capslock> ;-)

> 	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?
No No No.
* Don't hide the fact that stripped binaries are (almost) useless for
  debugging.
* Don't split into "known vendor" and "unknown vendor"

> > > 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?"

"Hell" is having many many uneducated users with broadband connection
with a tool that generates automatic useless bugreports.



Geert Stappers
-- 
Education saves us from hell.