errors.ubuntu.com: support for Server?

[Robie Basak]

On Thu, May 16, 2013 at 07:01:54AM -0700, Evan Dandrea wrote:
> Why do you assume an opt-in system? Error reporting on the desktop is
> not opt-in, and for good reason: our data would be heavily skewed to
> the types of people who already know that the error reporting
> functionality exists, can find the toggle to turn it on, and are so

What I mean is that data does not get uploaded without the user knowing
about it. So in my terms, error reporting on the desktop _is_ opt-in. In
the Desktop case, the user knows about it when the error reporting
dialog pops up. In the Server case, this is more difficult to achieve,
since there is not necessarily any UI available to prompt the user after
an error.

> I'd prefer that we kept with the existing model of not asking
> questions, as this has been core to the redesign of apport and the
> development of the error tracker.

OK, but we do effectively ask a single question on the desktop, right?

> 1) We have been historically quite bad at understanding our audience
> when programmatically communicating with them.

[...]

> 2) Any extra bit of work you put between a user and submitting an
> error report will cause some of those users to not send the report.
> They'll be hesitant to send subsequent reports if the process was
> previously onerous.

Agreed - we need to make sure that the UX is as simple as possible.

[...]

> I think we should find a solution with that balance in mind. I've
> suggested in the past that we do this at installation time with the
> default option being to enable error reporting. So in the case of
> debian-installer, a d-i component that asks whether you want to
> disable error reporting. In the case of juju and maas, I'm not sure.

This is certainly worth considering.

> > Some implmentation ideas:
> >
> > Production server operators may want to vet reports before agreeing to
> > send them, so an interactive CLI like aa-logprof(8) or apport-cli(1)
> > that allows users to see exactly what they are submitting would be
> > useful. So essentially a CLI equivalent of the GUI error reporting
> > dialog.
> 
> The documentation for apport discusses one possible approach:
> 
> http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51
> 
> The problem I have with this is that it's a very manual step. I'm not
> convinced many people who would otherwise be okay with automatic
> reporting will actually notice the message and follow through. It also
> delays our knowing the frequency of serious issues by relying on
> server administrators to log in and process the reports.

Could this be reasonable as one fallback position for those who ask d-i
to turn off automatic uploads, or if we choose not to follow that path?

> > Or perhaps some kind of remote ssh enhancement to the existing GUI error
> > reporting dialog, so users get the same UI on a desktop machine that
> > connects to a server machine, picks up the crash reports there generates
> > and sends reports via the local GUI?
> 
> That assumes they're running Ubuntu everywhere. It's presumably
> confusing as you're suddenly getting error reports out of the blue.
> We've been bitten hard by this with the "system internal" error
> reports that pop up, confusing users who thought they hadn't actually
> done anything.
> 
> But most importantly, it's extra work for the end-users to get going.
> Lets make the barrier to sending these reports as low as possible.

Fair enough.

[...]

So where do we go from here? It seems that we have two proposals:

0) I presume that with both proposals we have the option of choosing
different defaults between stable and development releases?

1) A d-i prompt asking about error reporting. Outcome: automatic uploads
of error reports, or not. I understand that you want this to default to
automatic uploads, and your reasons.

2) The bash prompt modification at [1] by default.

For MAAS, I presume that we could make the d-i preseed configurable at a
global level.

I'm not sure about juju without MAAS. Perhaps a configuration parameter
for the environment could feed cloud-init?

Any other proposals from anyone?

Robie

[1]: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20130524/b7d26257/attachment.pgp>