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@xxxxxxxxxx | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
