> 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.
The toplevel idea that users shouldn't care about updates is great.
Some advanced users do care about updates, but most end-users shouldn't
have to worry about applying security or stable updates or getting new
versions at any time. This is the experience you get with new
Chrome/ChromeOS, new Firefox, new websites, new Android or iOS apps.
You might get a summary of the changes if you care. People reading this
thread might be reading the changelog of security updates, but non-IT
folks just press the big "apply all updates" button or just get the
updates applied in the background.
I don't think the problem is with the size of the updates though; at the
moment we bundle the OS and the apps in one large archive where
everything in it has to transition in lock-step and where end-users can
combine things in a crazy number of ways, allowing them to e.g. update
only this or that part of their system.
It's urgent that we draw some lines between things that are core in this
or that Ubuntu flavor (you can't touch these, these get updated
regularly wholesale and unintrusively for you) and things you add on
top (mainly apps, that need to keep working because they are built on a
decently stable API).
Another major difference is in time-based releases vs. rolling vs.
roughly monthly releases.
Pushing end-users to LTSes is too limiting for us; it would take too
long for people to consume our work. Pushing them daily stuff is too
aggressive. We're still doing sourceful uploads without any kind of
manual testing, we're stll getting regressions every day without any
kind of human testing before it reaches everyone on the rolling release.
These get fixed quickly, but this should not reach regular
non-developers.
> 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.'
I don't even know whether we want that many choices, but clearly that's
what we should be thinking about.
If I take Chrome as an example, I can see how you can be interested in
testing latest crack to integrate with it, report issues with it, get it
first before you're interested etc. but you know you might get bugs; so
you'd be on the beta or dev channels, just like one can get Firefox
beta. But most users are on the stable channel or use the non-beta
Firefox and they get updates all the time, but updates that have been
staged in various ways and hit them from time to time, often without
them even noticing.
There might be a fundamental split here between server deployments or
old-world IT approaches where you want tight control over what comes in,
use the same bits for a long-period. Clearly that's not what we want
for client where we want our stuff to reach as many people as possible
as soon as possible, but not too soon as it needs to be good enough.
The current -proposed step isn't sufficient to stage changes; the
proposed monthly releases might be more suitable, but I don't really
like them because they are either suck too much effort to get them good
enough or they would not be good enough.
My preference would be for some kind of Ubuntu + Unity base rootfs that
people can't touch; their apps are installed in some separate hierarchy
and they can update their Ubuntu + Unity base rootfs efficiently all the
time to get security fixes and latest features. We would have an easy
way to push an update for a security fix, and an easy way to stage what
goes in it. We do need some branch of (a subset of) the archive to
build that though.
--
Loïc Minier
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
