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) | ||
''How To Test'' looks good. Somehow we are missing the ''User Experience'' and ''Release Notes'' sections. Please complete them too. This needs to completed before FESCo reviews. Thanks [[User:Poelstra|poelcat]] 17:50, 16 November 2010 (UTC) | |||
== Other question == | == Other question == | ||
Revision as of 17:50, 16 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)
How To Test looks good. Somehow we are missing the User Experience and Release Notes sections. Please complete them too. This needs to completed before FESCo reviews. Thanks poelcat 17:50, 16 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.