errors.ubuntu.com: support for Server?

[Evan Dandrea]

On 24 May 2013 17:20, Robie Basak <robie.basak at canonical.com> wrote:
> On Thu, May 16, 2013 at 07:01:54AM -0700, Evan Dandrea wrote:
> 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.

Ah, thank you for clarifying.

>> 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?

We do. By "not asking questions" I mean not asking any questions
beyond what is absolutely necessary. So yes, at some point we need to
ask for their consent in sending all error reports, with each one, or
even some combination of both – saying "no" to automatic error
reporting could still notify you via motd that you have reports to
manually process.

What I do not think we should do is ask questions beyond that.
Historically they've been confusing to our audience, but more
importantly they reduce the likelihood that someone will respond. It's
extra work, and they might not have the time for it.

There are better ways. We can use scale to our advantage and given a
report that's missing some critical detail we didn't anticipate,
programmatically tell the next reporter's system to attach additional
information. This involves no additional human interaction and is
theoretically as fast as a few seconds as opposed to the usual
Launchpad bug response time of days or weeks, if ever.

>> 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.

Great!

>> > 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?

Yes, I think unless the user explicitly disables the collection of
reports (disabling apport in /etc/default/apport), we should still
tell them what it's doing and how they can further process the
results.

So I would be very happy in taking that .bashrc chunk from apport and
putting it in motd as a first step.

> 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?

Yes, though do keep in mind that if we restrict ourselves to just
development releases we are going to miss out on problems that would
only crop up post-release. We've had serious ones with each new
release of the desktop OS.

> 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.

Yes please.

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

Yes please. :)

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

I'm intimately familiar with preseeding, that being my former life and
all, but I'm afraid I don't know what you mean by "global level." I
take it that's something related to MAAS?

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

That's vaguely what I was thinking. Either using constraints or kindly
requesting that a new environments.yaml option be added to represent
error reporting. The benefit of the latter is that's it's more
discoverable, even if disabled by default. We could automatically
populate it into environments.yaml with a comment explaining what it
does and asking them to help make Ubuntu better by turning it on.

We should ask them directly though, perhaps as a separate discussion
to this one.

Thanks!