From Fedora Project Wiki
(Created page with '== Wrangler Review 2010-11-04 == Please complete the ''How To Test'' section--we need some idea how a person would go about testing this feature. Thank you. ~~~~') |
No edit summary |
||
| Line 4: | Line 4: | ||
Thank you. [[User:Poelstra|poelcat]] 16:41, 4 November 2010 (UTC) | Thank you. [[User:Poelstra|poelcat]] 16:41, 4 November 2010 (UTC) | ||
== Other question == | |||
--[[User:Dmalcolm|Dmalcolm]] 20:44, 15 November 2010 (UTC) This approach seems to have some drawbacks: | |||
* the user has to send the coredump across the internet to a Fedora site, and the coredump might contain sensitive information. The user has no way of telling if the backtrace will contain sensitive information until the analysis is received back from the remote server | |||
* the coredump may be rather large (many megabytes); some people may object to uploading many megabytes to a remote site; many people have asymmetric connections to the internet, where upload rates are considerably slower than download rates. | |||
Alternate approach: make the debuginfo sources be downloadable from an internet-visible fileserver, and do the analysis on the user's machine. The rpms could be unpacked on demand. The user's computer would merely be downloading small amounts of public information, rather than sending large amounts of private information. I believe Will Woods was working on something like this. | |||
Revision as of 20:44, 15 November 2010
Wrangler Review 2010-11-04
Please complete the How To Test section--we need some idea how a person would go about testing this feature.
Thank you. poelcat 16:41, 4 November 2010 (UTC)
Other question
--Dmalcolm 20:44, 15 November 2010 (UTC) This approach seems to have some drawbacks:
- the user has to send the coredump across the internet to a Fedora site, and the coredump might contain sensitive information. The user has no way of telling if the backtrace will contain sensitive information until the analysis is received back from the remote server
- the coredump may be rather large (many megabytes); some people may object to uploading many megabytes to a remote site; many people have asymmetric connections to the internet, where upload rates are considerably slower than download rates.
Alternate approach: make the debuginfo sources be downloadable from an internet-visible fileserver, and do the analysis on the user's machine. The rpms could be unpacked on demand. The user's computer would merely be downloading small amounts of public information, rather than sending large amounts of private information. I believe Will Woods was working on something like this.