Updates next steps

[Owen Taylor]

On Fri, 2010-04-23 at 15:30 -0400, Matthias Clasen wrote:
> On Fri, 2010-04-23 at 14:06 -0400, Seth Vidal wrote:
> 
> > 
> > so it seems like in lieu of changing our updates policy right now we 
> > should:
> > 
> > 1. continue the autoqa work
> > 2. help those checks have more/better meaning for our 
> > packagers/developers/contributors
> > 
> > and then reassess things once the autoqa is in place and being enforced?
> 
> We need to do both of these things, for sure. 
> 
> And we can address part of the 'update frequency' problem client-side,
> by only checking for new updates once a week. 

How would you get security updates then? A week is a pretty long time to
wait, if, say, we had a header-parsing bug in Evolution that allowed
remote code execution.

> But one problem which we cannot address client-side, and for which 'do
> nothing now and reassess later' will not help at all is the amount of
> updates. Even if you only check once per week, the flood of pointless
> updates is a problem. That is that part of the problem that we need to
> address with Jon's 'establishing norms or rules to limit changes'.

It's a multipart problem. We need think in terms of "budgets".

 A) How many times does the user get asked to interact with us to 
    update the system?

 B) How many times does the user get asked to reboot?

 C) How much CPU/IO/bandwidth do we use to install updates?

 D) How many times does the user experience change in ways that might
    confuse users?

 E) How many times do we accidentally break the system? 
    [ budget == 0... ]

Exceeding our budget in any of these areas will make users unhappy.

Batching up updates to once a week helps with A) and B), and maybe with
E) if it means we do more testing, but doesn't help with C) and D).

- Owen