Handling Failure Gracefully
In the real world there are always going to be failures, triggered by
things like software bugs, hardware failures and misconfiguration.
Ubuntu should where possible handle common failures and provide
predictable feedback to the user that the system is broken.
Blueprint information
- Status:
- Not started
- Approver:
- Sebastien Bacher
- Priority:
- Medium
- Drafter:
- Robert Ancell
- Direction:
- Approved
- Assignee:
- Robert Ancell
- Definition:
- Approved
- Series goal:
- Accepted for quantal
- Implementation:
-
Deferred
- Milestone target:
-
ubuntu-12.10-beta-1
- Started by
- Completed by
Whiteboard
Work done in precise:
[robert-ancell] Produce list of things we can detect and actions to take (https:/
[bryce] get failsafe-x working: DONE
pitti, 2012-03-28: Moving blueprint to Q, as most stuff is still open.
mathieu-tl, 2012-07-04: ncurses network-manager not required; we already have nmcli which ships with NM and provides a way to create new connections for wireless networks now.
Work Items
Work items:
[cyphermox] investigate ncurses network manager connection: DONE
Work items for ubuntu-
[ev] Ensure that for any of these failures we're recording apport crashes: POSTPONED
[ev] If a crash occurs and the user has crash database reporting turned on, automatically create the .upload file so that it gets uploaded the next time there is internet: POSTPONED
[ev] Work out methods for storing flags to detect boot failures: POSTPONED
[jamesodhunt] discuss with mvo+stgraber how we might pass data into friendly-recovery so we can display a message suggesting the user select a particular option: POSTPONED
