So...can we make a decision on this today? How should we do that? Have the current WG members vote? https://fedoraproject.org/wiki/Cloud/Governance

Executive summary here:
- Break easy rebasing from F21 -> F22, gain rebasing from Fedora <-> CentOS <-> RHEL forever
- Support rebasing from F21 -> F<N> forever

Forever is a long time. :)

Yes, having a WG vote is the way to go. (FWIW, as a non-voting member, I think it makes sense.)

Typically we look for lazy consensus over at least 72 hours. Since we don't have that time to make a decision in this case, if we can get a quorum vote in favor (or I guess, against) then we have a decision.

I'm a little nervous about this given that if it breaks anything, we may well not have an Atomic release for F22. However, I believe Colin is saying this is unlikely to break the compose and if he's confident... then I will +1.

So - +1.

Others?

I think there were concerns voiced in the meeting this past week. We had discussed waiting to make this change when we moved to Atomic as a spin, but we also discussed the possibility that the adoption of F21 atomic may be low enough to diminish worrying too much about breakages.

I'm +1 for the change but I do encourage us to think about the change and the community. We wouldn't really be giving too much warning to people.

Dusty

normally we say you can update from alpha on up. as i understand it this would break that. I am not advocating any option, just pointing out something to consider

Dusty - I agree, but this is an anomaly, we have so much churn in the featured software (Docker, Kubernetes, etc.) that the users should understand that there's going to be some bumps in the road. If this was a more mature set of tools, I'd argue against this - but in this case I think we need to err on the side of progress. Especially since it's not a question of "if" we're going to break things but "when" -- let's do it quickly.

Replying to [comment:6 jzb]:

Dusty - I agree, but this is an anomaly, we have so much churn in the featured software (Docker, Kubernetes, etc.) that the users should understand that there's going to be some bumps in the road. If this was a more mature set of tools, I'd argue against this - but in this case I think we need to err on the side of progress. Especially since it's not a question of "if" we're going to break things but "when" -- let's do it quickly.

Agreed. +1

Replying to [comment:6 jzb]:

Dusty - I agree, but this is an anomaly, we have so much churn in the featured software (Docker, Kubernetes, etc.) that the users should understand that there's going to be some bumps in the road. If this was a more mature set of tools, I'd argue against this - but in this case I think we need to err on the side of progress. Especially since it's not a question of "if" we're going to break things but "when" -- let's do it quickly.

I have no voting rights here, but I'm in favor of breaking things now and feeling the pain, rather than waiting for the next release.

Pushed. It'd be great if people beyond me could give the result some testing tomorrow/Monday.

I tested by rebasing between a tree generated by
https://github.com/CentOS/sig-atomic-buildscripts/tree/downstream
and one generated by this commit.

To make this easier to test, we need CentOS downstream rebuild of the ISO and cloud images published, and a publicly available Fedora tree with this commit. Both are in progress.