Apport Enhancement

Rationale

The current implementation of Apport message dialogues and notifications has a poor logic and does not benefit user experience over time.

Thu user is exposed to lots of message dialogues when multiple crash reports are detected at the same time.

Proposal

• Conditionally show message dialogue for batch crash report submit according to some logic explained below.
• Reduction of message dialogues visible on-screen simultaneously when a crash report is detected by implementing single instance message dialogue app
• Keep record of unreported crashes
• Add counter of unreported crashes en message dialogue
• Update on real time the counter when new crash report is detected
• Add persistent indicator when unreported crashes are detected.

Indicator

• Always: libindicator tray icon with counter
• Always: libnotify desktop-notification each time sudoer user is logged in.
• Conditional: message dialogue each time sudoer user is logged in, only if current number of reports is greater than interval-counter modelled as Fibonacci series.

Outdated packages

• Explain if necessary if report could not be sent due to outdated packages
• Offer package updates or launch update-manager if necessary.
• If auto-launched, explain in update-manager that an update is necessary to check if previous problem(s) is(are) already solved on newer version(s).

Intervals (interval-counter)

To avoid receiving too much reports from only one user, a persistent counter could be added. Basically, it increases every time a user sends a batch of reports, this way a few advantages are achieved:

• As long as times goes, user is less interrupted with notifications. Usability is exponentially-amortized enhancement; gets better as times goes by
• Could bring less false positives
• Ubuntu gets less reports from broken or experimental settings, such as when a user installs and reconfigures services just for the fun of it
• More batch of reports are gathered on fresh installs
• No interval logic should be considered on development versions.

Uptime

• Implement some logic to conditionally show notification when very long uptime is reached (ie, 100 Hours)
• Implement some logic to conditionally skip message dialogue show on login (or start-up) if last uptime was less than 1 Hour (for barely used systems).

Network Connection

• Server Downtime: do not show notifications or message dialogue when bug tracker could not be reached
• Mobile only: Implement some logic for users of mobile connections to avoid spending too much data quote if applicable
• * Prepaid: interval based on double counter value (2i) for prepaid (when user can't afford spending too much on updates and crash reporting). Not sure about this one.

Privacy

• Encrypt crash reports and unencrypt when submitting
• If encryption is implemented, automatically collect user data and stack traces and only submit if user authorizes it. Otherwise discard sensitive reports presents in the batch.
• If encrypted by SSH keys, discard or re-encrypt previous reports after successful new key pair is generated.