On 01/18/2010 09:34 AM, Alexander Larsson wrote:
On Mon, 2010-01-18 at 09:31 +0100, Alexander Larsson wrote:
On Sun, 2010-01-17 at 13:02 +0000, Camilo Mesias wrote:
Having said that the things that can be done with a mere backtrace
are
limited. I would almost always need to look at the corefile too, and
would be frustrated if it wasn't available. Perhaps the workflow
that
starts with ABRT providing a backtrace needs to be significantly
different to the workflow for a manually submitted bug. More
automated
perhaps?
What if every component had a placeholder bug for undiagnosed ABRT
info. Keeping all of them together would help to gauge which are
significant and which are one-in-a-million cosmic rays flipping RAM
bits etc.
I think it should work more like the mozilla crash handling system.
They
file automatic crash reports in a completely different database which
is
more optimized for e.g. data mining and is less work for the
maintainer
on a per-bug basis. So, instead of replying and keeping track of every
user crash manually the maintainer gets list of "top crashers it
latest
version", "new crashes this week", etc.
In case you're interested this is how the mozilla database looks:
http://crash-stats.mozilla.com/
I agree. The current infrastructure doesn't go well with ABRT. To be
able to detect duplicates we need to compare the whole backtraces not
just hashes and that can't be done with bugzilla(the only way to do this
is to download all backtraces from bz and compare them on user computer,
which is really not acceptable). So having similar server as Mozilla
uses is our plan also. Then we can recreate (without sending a core
file) the trace on server without forcing users to install the debuginfo
and process the whole BT the way we want without consuming users CPU
time, etc..
Jirka
begin:vcard
fn:Jiri Moskovcak
n:Moskovcak;Jiri
email;internet:jmoskovc@xxxxxxxxxx
x-mozilla-html:FALSE
version:2.1
end:vcard
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
