Monthly Updates versus Monthly Images

[Allison Randal]

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