Merge lp://staging/~brian-murray/daisy/raring-eol into lp://staging/daisy

26 + elif 'kernel crashes' in text.lower():

This should be 'Kernel crashes'. Otherwise looks good.

Given that whoopsie expects only a 200 or 400 response code:

        if (response == 200 || response == 400)
            success = TRUE;
        else
            success = FALSE;

We shouldn't be returning a 410 or 501. We could updated whoopsie in Trusty with these new response codes and then check the X-Whoopsie-Version: to decide whether or not to return the new codes.

On 31 January 2014 17:29, Brian Murray <email address hidden> wrote:
> Given that whoopsie expects only a 200 or 400 response code:
>
> if (response == 200 || response == 400)
> success = TRUE;
> else
> success = FALSE;
>
> We shouldn't be returning a 410 or 501. We could updated whoopsie in Trusty with these new response codes and then check the X-Whoopsie-Version: to decide whether or not to return the new codes.

Given that this code is specifically for raring, shouldn't we just
reuse the 400 error code?

The rationale for the error tracker is to answer two questions: (1) How reliable is Ubuntu right now? (2) What's the best thing I can do right now to improve Ubuntu's quality?

Now imagine we discovered that Ubuntu 12.10 was our Windows XP: that 40 percent of Ubuntu users, today, were using it. The answer to question (1) -- the overall experience of Ubuntu users in general -- would be heavily influenced by the reliability of 12.10, *regardless* of the fact that it is EOL. So we'd know that the answer to (2) would be not so much to fix bugs in Trusty, but urgently to figure out what was preventing 12.10 users from upgrading and to fix that.

We have, privately, been using error report submissions as a guide to what proportion of Ubuntu users are using what versions from 12.04 onward. If we stop accepting error reports from EOL releases, do we have an alternative way of measuring that?

If not, instead of just rejecting a 12.10 error report outright, could we perhaps accept it an empty record -- remembering that an error was reported on 12.10 for counting purposes, but not bothering to retrace it?

I do think the lines on the error graphs for any version should end on the date that version reaches EOL. Otherwise the line will just get noisier as the number of machines gets tinier. But I don't see anything that does that in the diff.

@Evan I thought we had talked about wanting a way to tell on the client that the submission was unsuccessful due to the client OS being unsupported, however given that we can't update whoopsie on Raring we'll just have to reuse the 400 error code. But I think we should implement these new error codes in whoopsie and SRU the changes to P, Q, S.

On Mon, Feb 03, 2014 at 11:05:17AM -0000, Matthew Paul Thomas wrote:
> The rationale for the error tracker is to answer two questions: (1)
> How reliable is Ubuntu right now? (2) What's the best thing I can do
> right now to improve Ubuntu's quality?
>
> Now imagine we discovered that Ubuntu 12.10 was our Windows XP: that
> 40 percent of Ubuntu users, today, were using it. The answer to
> question (1) -- the overall experience of Ubuntu users in general --
> would be heavily influenced by the reliability of 12.10, *regardless*
> of the fact that it is EOL. So we'd know that the answer to (2) would
> be not so much to fix bugs in Trusty, but urgently to figure out what
> was preventing 12.10 users from upgrading and to fix that.
>
> We have, privately, been using error report submissions as a guide to
> what proportion of Ubuntu users are using what versions from 12.04
> onward. If we stop accepting error reports from EOL releases, do we
> have an alternative way of measuring that?
>
> If not, instead of just rejecting a 12.10 error report outright, could
> we perhaps accept it an empty record -- remembering that an error was
> reported on 12.10 for counting purposes, but not bothering to retrace
> it?

The meterics.meter call will cause a counter in statsd to be incremented
which should be sufficient. However, I've only called labelled this as
unsupported.end_of_life and will change it to be release specific.
Thanks!

> I do think the lines on the error graphs for any version should end on
> the date that version reaches EOL. Otherwise the line will just get
> noisier as the number of machines gets tinier. But I don't see
> anything that does that in the diff.

I think the easiest way to fix this is to remove Raring from the cronjob
that updates the unique users count for that release. As I discovered
last week not having this running for Trusty was preventing any data
from appearing on the graph for that release and just starting the
cronjob created the line from the date the job started. So removing the
Raring cronjob should force the line to stop today which seems close
enough.

--
Brian Murray