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