dustymabe added a new comment to an issue you are following: `` @jberkus - i'm fully operating in many contexts. I'm thinking about many different use cases where systems are upgraded manually and where systems are upgraded automatically. What I would like to do is operate on a principle of least surprise. Up until this point I would say that upgrading from one major release to the next around "major release day" would have been a really rocky process that isn't necessarily something that people would want to happen without knowing what they were upgrading to beforehand. This is a big reason why I would want to make "automated major upgrades" a configurable option, so the user can choose the behavior. Since we are now working more effectively as a working group, maybe we'll be good enough to make sure that transitions from one release to the next go more smoothly than they have in the past. I agree that kubernetes and/or docker have been the largest agents for "pause" on performing major upgrades. Agreed that if we remove those variables then a single stream becomes less of a concern. It might be the wrong time to do this, but I'll bring it up now. I personally like the fact that we have different ostree repos for different major versions of Fedora. This allows us to timebox adding updates to the repo (meaning it doesn't grow in size forever; yes pruning exists, I know), as well as create new repos periodically in the future (think new mode for storage for ostree repo that we want to start using). If we support "automatically going to the next major version" we either need to combine the ostree repos into one repo or we need to support some sort of automated "add remote + rebase" support in ostree/rpm-ostree. Can we resolve what we would need to do about this particular issue? I prefer automated "add remote + rebase", but that isn't something that exists today. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/231 _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
