| 2012-10-30 17:15:58 |
Matthew Paul Thomas |
description |
Some errors are fixed by updates. But an update is effective only if it is installed.
We have data about how quickly updates are installed, because the frequency of an error goes down after an update is published. But we don't have a way to visualize this data.
I suggest presenting it like this:
Let the *relative error rate* of an error, on a day, be the error rate (not the raw frequency, but the error rate) of just that error on that day, divided by the maximum rate that error ever reached. So on its most common day, the relative error rate for any error is exactly 1.
Let U = the date when an update is issued.
Then for each error that is fixed, calculate the relative error rate for each day, in a date range from about U–14 to about U+28.
Finally, plot the averages of all the relative error rates for U–14, U–13, U-12, and so on through to U+28.
The graph should look like half a skateboard halfpipe: fairly flat where the date < U, dropping steeply shortly after U, then flattening out. |
Some errors are fixed by updates. But an update is effective only if it is installed.
We have data about how quickly updates are installed, because the frequency of an error goes down after an update is published. But we don't have a way to visualize this data.
I suggest presenting it like this:
Let the *relative error rate* of an error, on a day, be the error rate (not the raw frequency, but the error rate) of just that error on that day, divided by the maximum rate that error ever reached. So on its most common day, the relative error rate for any error is exactly 1.
Let U = the date when an update is issued.
Then for each error that is fixed, calculate the relative error rate for each day, in a date range from about U–14 to about U+28.
Finally, plot the averages of all the relative error rates for U–14, U–13, U-12, and so on through to U+28.
The graph should look like half a skateboard halfpipe: fairly flat where the date < U, dropping steeply shortly after U, then flattening out.
If these graphs for each Ubuntu version are overlaid on each other, we can see whether changes in Ubuntu versions have caused updates to be installed more quickly or more slowly. But we should be wary of:
- the sort of people who install non-LTS versions being more likely to install updates quickly anyway
- update penetration slowing regardless of version, as an increasing user base includes a greater proportion of people who don't install updates quickly. |
|
