On Wed, Mar 06, 2013, Robert Collins wrote: > 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