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 backtracearelimited. I would almost always need to look at the corefile too, and would be frustrated if it wasn't available. Perhaps the workflowthatstarts with ABRT providing a backtrace needs to be significantly different to the workflow for a manually submitted bug. Moreautomatedperhaps? 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
<<attachment: jmoskovc.vcf>>
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
