Daisy

Code review comment for lp://staging/~brian-murray/daisy/raring-eol

raring-eol
Merge into trunk

Revision history for this message

Brian Murray (brian-murray) wrote on 2014-02-04:

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

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

« Back to merge proposal