Monthly Updates versus Monthly Images

[Scott Kitterman]

On Wednesday, March 06, 2013 04:12:16 PM Robert Collins wrote:
> On 6 March 2013 12:20, Scott Kitterman <ubuntu at kitterman.com> wrote:
> >> critical updates.  I think leveraging phased-updates to that end is a
> >> fairly simple, lightweight, and elegant solution that completely avoids
> >> the
> >> harm and complexity of any of the proposed monthly updates schemes.
> > 
> > I think for phased updates to be meaningful in this context it would have
> > to be a bit different.  As (IIRC) Highvoltage mentioned, he wants to be
> > at the back of the iceberg:
> > 
> > http://hellenicpolytheist.files.wordpress.com/2012/07/killer_whale_eating_
> > penguins- jump-in-air.jpg
> > 
> > What's needed is not only show me updates every X days, but only show me
> > non- critical updates that are at least X days old.  I don't think we
> > have a way to express that.
> 
> I think this is backwards: we're trying to cross the chasm; users
> don't want to have to care about updates *ever* - the industry is
> moving to a model where knowing that something has updated, or not, is
> quaint. First websites started to evolve rapidly, with occasional
> 'whats new' dialogues, a long time back now virus scanners and other
> critical time-sensitive components on other operating systems started
> just keeping themselves up to date all the time, and less critical
> components prompt.
> 
> Most users *do not have* the knowledge about our development practices
> and the reliability we achieve to reason about 'should I update daily,
> weekly, monthly or 2 years'. It is a nonsensical question. They can
> reason about how much risk they are willing to take: 'No risk at all
> of new things breaking but I may get cracked and nothing gets better'
> / 'Low risk of things breaking but I get security updates to avoid
> crackers - but nothing gets better' / 'Things might break but I get
> security updates and the software gets better.'
> 
> Exact frequency is *only* meaningful because we have bugs in our
> delivery infrastructure: we routinely ship 10 or 100 times as much
> data as is needed (no binary deltas); we ship 10 to 100 times as much
> metadata as is needed by most users (complete archive index for
> everyone all the time, and no archive deltas); installation of package
> updates reads again, 10 to 100 times as much data as is being altered
> (change 10 packages on a system with 1000 installed, but we read the
> full dpkg status file, the complete list of all files installed by any
> package...); dpkg is slow (because it works very hard to be atomic).
> 
> Now clearly we can't wave a hand and just fix all those issues (and
> there probably will even be debate about whether they are all in fact
> issues :p) - but when we design what we want to achieve, lets design
> around our users, what we can reasonably expect them to know and care
> about, rather than around the plumbing we happen to have today, which
> they assuredly are not interested in.

If that's the kind of users we're targeting with the rolling concept, then 
it's way premature to consider switching to it.  That doesn't mean we can't 
define the technical needs that would make us ready and start working towards 
it now, but execution should not precede readiness.

If the target is a more advanced "enthusiast" user, then I think they do know 
about updates and will have some care about them.  I'm not proposing that we 
give rolling users a knob to turn to decide how far back on the iceberg they 
want to be, just that there be an offset for "enthusiast users" who are not 
directly involved in development.  

Scott K