Re: Subject: Re: Stock response addition
- From: Fernando Herrera <fherrera onirica com>
- To: Elijah Newren <newren gmail com>
- Cc: sri aracnet com, gnome-bugsquad gnome org, "hala cse unsw edu au" <hala cse unsw edu au>
- Subject: Re: Subject: Re: Stock response addition
- Date: Tue, 23 Nov 2004 21:24:26 +0100
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
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
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 :).
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?"
] [Thread Prev