Automatic bug reporting not so automatic

[Fred]

Apport or whoopsie could use a setting for automatically sending a crash to the database without any user interaction.

Original report follows:

The automatic bug reporting is not so automatic.

When an application crashes, it triggers "Apport" to run.
It asks the user if he wants to submit a bug report, and the user can select yes or no. (Good)

However, when the user clicks on the "Send bug report" button, it opens the web browser and redirects him over here to bugs.launchpad.net

Most (especially new) users, don't want to bother register an account on the website and enter a description.

If an application crashes and they're asked two choices "Report crash" or "Don't report crash", many will click on the "Report crash" if it causes no personal inconvenience, effort or loss of time for them.
But non-technical users, don't want to report it, if it brings up a website where they need to register an account and enter a description.

So I propose to make it so the user can quickly send a bug report without inconvenience, effort or time, by just pressing a button, and it sends it without the user have to have an account or type anything.

[Fred (eldmannen+launchpad)]

Using Apport to report a bug should not require a launchpad account. It should be optional.

When you click on the "Send bug report" it should send the bug report straightaway and say;
* "Thank you for reporting a bug. We will look into it and hopefully fix it soon. We really appreciate your help, if you want to help us more, please provide some optional relevant information on what you did when this bug occurred and how to reproduce it."

[Fred (eldmannen+launchpad)]

Bug reporting should be as quickly, easy as possible.
Bug reporting should never be an inconvenience to the user!

It is great if the user provides valuable information.
But it should never require the user to do more than to press a button, unless he wants to.

... in another operating system that I know, the user justs clicks "Send bug report" without have todo anything else. Convenient!

[TerryG (tgalati4)]

I agree with reporter. However, the website registration does enforce some discipline and allows bug reports by serious users and those patient enough to go through the registration process.

It would be nice if the user was presented with 3 options: Quick Bug Submission, Detailed Bug Submission (Requires Launchpad Account), Quit

Presumably there would be a lot of Quick Bug Submissions without a lot of detail--perhaps just machine architecture and application. That info could be collected by a server to triage the 80/20. Which 20% of the applications is causing 80% of the bugs. Use the detailed bug reports to capture the use cases, replication and work arounds.

Focus the Bug Hug Days on the 20% bad actors.

[Fred (eldmannen+launchpad)]

Yes, surely having users with accounts are good because it makes it more serious, and makes so you can reply to the reporter, and he can provide additional information, help out more, and say if it gets fixed or something.

Then we get the reports sorted into two categories, "anonymous noobs", "serious bug reports by people with accounts".

Assuming people would report if it was simpler and didn't require an account, then we benefit because we get more reports.
Unless it also makes less people (who would otherwise) register.

[TerryG (tgalati4)]

Here's what I envision: A new rhythmbox is released and pushed out to the masses. It incorporates a new feature called crazy jukebox where it makes all your windows wobble to the music (please don't code this!). The developer is so excited about this new capability that it is pushed out the door and enabled by default.

Joe User sees a new rhythmbox and selects update. He wants to listen to music--BAM rhythmbox crashes (presumably because either wobbly windows is not enabled or compiz is not running). Crash dialog comes up presenting 3 options: Quick Bug Report, Detailed Bug Report, Quit.

The Quick Bug server gets hammered with reports of rhythmbox crashes. Server is set to send email notice to developer after 5 hits in the past hour--automatic triage. Quick Bug reporter has no expectation of getting email notices of bug fix progress. Developer digs the crud out of his eyes the next morning and sees some detailed bug reports from irate users and a warning email from the Quick Bug server. Something is up with the new version. A quick read of the bug reports: Work around: Turn Off Crazy Jukebox!

Developer quickly sees that this new rhythmbox capability interferes with several use cases: older machines without compiz, headless machines, machines with compiz but with wobbly turned off, etc . . . Developer makes changes adds a glx check, turns off crazy jukebox by default and adds a warning dialog when it is activated. New release is submitted to Q/A.

Q/A is busy and new rhythmbox is at the bottom of the stack. Quick Bug server sends an email to Q/A when reports exceed 20 during the past hour. Whoa, better look at rhythmbox. Patches submitted, need to perform test suite on rhythmbox (or whatever Q/A does) then push the release. Q/A runs a Quick Bug report on rhythmbox to see that the growing mountain of bug reports is dropping quickly.

Back to work on Bug #1.

[floid (jkanowitz)]

I wrote the following as my "first impressions" whinge after actually following through a report with apport [for an issue I wasn't "invested" enough in to report manually], after starting the process and giving up many times prior.

I'd hate to just discard the wall of text I've built, but the conclusion is in line with TerryG above... with some other items that should be split out as separate bugs but have probably been reported already. [I'm actually quite impressed how many issues have already been acknowledged and marked as triaged or WIP..]

Treating 'automated reports' as a separate type of object seems like the way to go. They're uninterpreted telemetry, the form is standardized, and aside from cutting down "Bug" noise and misreporting by not demanding they become "Bugs," they'd also be a lot easier to conduct standardized data-mining/graphing/reporting on if they weren't mixed in with our messy human-generated "Bug" objects (and the 'classification noise,' as people decide which components to blame) too. Let humans link the telemetry to "bugs" as they identify the real issue(s) the telemetry is representing, not before they know what's going on.

...and as sugar, let the lazy-reporters only receive notification [if they want] when their reports 'join' a bug object and when that bug is resolved, without the noise in-between - they'll have the link in the first notice if they want to check up on things. :)

So... all below are my initial observations, if they're any confirmation or inspiration:

------

I think this is my first time using (or more specifically, following through) with apport, and I can't avoid a gripe - hopefully "constructive." I've previously considered using it, or specifically followed half the steps of using it, but it's still less fun than a trip to the DMV. Why?:

* apport makes no promises. It's not making any statement about what it avoids collecting for privacy/security, so any user with half a clue is going to have to stop and read closely.
- Note that apport is potentially *more* dangerous than trusting Microsoft, since the apport data is going to be visible to the entire planet as soon as it hits Launchpad, not just some corporate campus.

* apport does show the raw data. This is 'completely honest', but:

- Obvious: Who wants a drink from the firehose?

- Inobvious: Use of the expanding list widget causes some misbehaviors / surprising behaviors when it comes to scrolling; it is also extremely easy to lose sight of which variable you're in once it scrolls out of view.

- Inobvious?: A user can be quite familiar with UNIX and still be completely unfamiliar with the xxx.xxx.xxx naming conventions in the report list. (Are those GConf-isms, Linux /proc-isms, or specific to apport itself?)
A legend would be handy here, even if just in some [Help]. Knowing it's just dmesg, `lspci`, `lsusb`, specific logfiles, etc. would make the vetting process re: "Am I about to boneheadedly disclose something I shouldn't?" go much faster.

- Obvious: It's all-or-nothing; if you go through the trouble of reading it all and *do* see something you'd rather obfuscate... time to give up and start all over manually...

[James P. Carter (jpcarter)]

Sorry so late to the party...

I would also like to add to this that there should be a way to automate reporting via the /etc/apport/crashdb.conf or perhaps the /etc/default/apport file. This would make certain it is the more technically inclined users "automating" and this would also speed up QA issues while cleaning up a new release. I could be wrong but I certainly would love to auto-report start up process failures and server instances that fail quietly.

Throwing the email address that we have registered with launchpad into the configuration would be cool, and then when we next login to launchpad.... "confirm bug submittal"... no need to authenticate during bug submittal however the interaction would still be there once we "confirm".

It's on the wishlist so... why not desire everything we can eh! ;-)

[Matthew Paul Thomas (mpt)]

Evan, I assigned this to you because I think merely switching from Launchpad to the crash database fixes the bug as originally reported, not because any extra mode is required. (Notice that it describes the visible choice as "Good".)

A completely silent mode may be useful, but I think that's separate from this bug.

[Bob Bib (bobbib)]

It's fixed in Precise.
---
apport (2.0.1-0ubuntu5) precise-proposed; urgency=low

  * etc/apport/crashdb.conf: Disable Launchpad crash/kernel reports for the
    final release. Leave Apport running for whoopsie, though, so use the new
    mechanism for selective problem types.
  * Cherry-pick from trunk:
    - data/general-hooks/generic.py: Bump minimum free space requirement from
      10 to 50 MB. 10 is not nearly enough particularly for /tmp.
      (LP: #979928)

 -- Martin Pitt <email address hidden> Wed, 18 Apr 2012 10:08:28 +0200

[Fred (eldmannen+launchpad)]

I don't think that reporting should be completely disabled.
Why is reports disabled in the final release?

Reporting issues is a good thing!
Presenting the user with a choice to report an issue, is a good thing.

I am just opposed to requiring the user to go through the inconvenience of registering an account on Launchpad.

[Fred (eldmannen+launchpad)]

Things gonna crash and users are not even presented with an option to report the issue?
I am sure that is gonna make users satisfied... -rolleyes-

[Matthew Paul Thomas (mpt)]

Fred, if you have tried 12.04 you will notice that it does still prompt you to report crashes, but it doesn't require you to sign in to Launchpad. All you need to do is click a button -- exactly what you suggested.

[Fred (eldmannen+launchpad)]

But now it seems reporting of crashes is going to be disabled in 12.10 Precise?

[Matthew Paul Thomas (mpt)]

Precise is Ubuntu 12.04, not 12.10, and reporting of crashes won't be disabled for either of them.