unity-design team mailing list archive

[Jonathan Marsden <jmarsden@xxxxxxxxxxx>]

Earlier I wrote, regarding presenting users with a list of updates:

> > would your proverbial grandmother have been similarly helped by
> > such a list?

mac_v replied:

> Atleast they would know / remember that the last thing they did was
> an update,

I disagree.  If they did a kernel update (your chosen example!) several 
weeks ago, and only just now rebooted their desktop machine, would they 
know that?  How?  They did a lot of other things in those intervening 
weeks.  Similarly, if an update updates (and breaks) an infrequently 
used application, or breaks just one infrequently used feature of a 
regularly used app... any resulting new issue may very well not be 
immediately visible.

> Or if the person is a bit more adventurous , can themselves search for
> the error...

Sure.  We already support this kind of search for "what might have 
caused this".  A log of which packages were updated when, under 
/var/log/apt/ , so they (either the user or someone helping them) can 
check on exactly what updates happened when.  This logging already 
happens.  Also, the system can use email sent by the auto updater to 
provide unobtrusive non-interrupting background "notification" of what 
was done, which is the approach used by the current, existing, 
functional, unattended-updates package in Jaunty.  It's configuration UI 
could IMO be made a lot easier for novices, and perhaps its logs could 
be easier to read... but the necessary functionality is already there.

> Updates not only in Ubuntu, in all OS *CAN* cause problems...

True; handling updates (whether automated or not) is a matter of risk 
assessment.  See my earlier response to ScottK for some ideas on 
migrating the work of doing such assessments to people with more 
likelihood of doing those assessments well, and away from a novice end 
user.  If you are advocating the outright rejection of any kind of 
automated updates, simply because too many Ubuntu updates *actually* 
cause problems (not "can", but actually *do*), then clearly you just 
identified an area in which it would be rather beneficial to our users 
to make some improvements!

Again I ask: can we avoid using anecdotes, and instead find good 
statistics on how big an issue this "the update broke my system" really 
is, to guide the discussion?  And if those stats do show high rates of 
breakage, then I really think the correct solution is putting some more 
effort into better QA of Ubuntu updates, along with providing a measure 
of automated update suitability -- not dismissing update automation per 
se as being too error-prone.

Jonathan