Atomic Updates - do we follow traditional model or a new one?

[Joe Brockmeier]

On 10/08/2014 08:55 AM, Matthew Miller wrote:
> I agree. And since we're making the packages from which the Atomic versions
> will be composed, what's the _downside_ of making releases available as
> distinct releases? Since it's produced from RPMs that we're making
> automatically, isn't it basically something we can offer to users with very
> little effort?

I see a few downsides:

* Having to test multiple releases. Not sure that quite fits under "very
little effort." (Maybe someday when we have automated testing, that will
be different.)

* Undermining the model that Atomic is supposed to support - which is
"you only care about the host as a way to run containers". As long as
Fedora 22 - 23 - 24 don't break anything within the set of functionality
they're supposed to offer (running containers, offering orchestration,
etc.) users *should not care* that it's Fedora 21 or 22.

I realize rpm-ostree makes some interesting things possible around
switching between trees - and that is something to explore for other
products, I think. But the use case here is supposed to be "my apps live
in containers. I need an OS that runs containers and maybe offers some
orchestration features. I'm not going to be tinkering with the host
itself, it's a pre-set unit and offers X,Y, and Z features. As long as
those continue to work, the details don't matter."

Telling users to worry about whether it's Fedora 21 or 22 or whatever
kind of reinforces old habits that this is supposed to get us away from.

Best,

jzb
-- 
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb at redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20141008/39efdc3c/attachment.sig>