On 03/06/2013 04:21 AM, Loïc Minier wrote: > > 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.
I was nodding along with this, and beginning to picture a 3-pocket model where: * -proposed is the cowboy-country where Debian syncs are automatic, FTBFS and other issues are held for developers to fix before packages go on to, * -testing is a solid candidate for end users, and where integration testing and translation work are done. On a regular cadence (monthly? weekly?) packages move as a set into, * The end-user visible archive. When a user is running the "rolling release" they get updates from this archive, not from -proposed or -testing. This is analogous to a DevOps model of "local VM" (where anything goes), a staging server, and a production server. Or in source control a topic branch, an integration branch, and a release branch. > 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. This sounds like an "abort" button when things go really, badly wrong. But not a solution to providing a stable user experience. Conflicts between installed apps and the base are real regressions. Allison -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
