Oops, this was meant for the devel list, not the desktop list (though it's definitely desktop relevant!) I'll resend it there, and please reply to the resend instead.

Thanks! Owen On Tue, Nov 27, 2018 at 10:30 AM Owen Taylor otaylor@redhat.com wrote:

One of the key parts of making a decision to delay/skip F31 is figuring out, ahead of the decision, what the expected experience is for users and packagers. Does F30 have normal stability, or do we try to keep users happy by moving things forward with ad-hoc updates and cross-our-fingers and hope nothing breaks?

I tend to think about this in terms of GNOME - would we rebase to GNOME 3.34 in the middle of F30 or not? But there's a lot of other pieces of software where similar considerations apply: container tools, cockpit, NetworkManager, etc.

And if we did do updates like that, would we consider respinning media and making a "F30.1"?

Owen

On Tue, 2018-11-27 at 10:30 -0500, Owen Taylor wrote:

One of the key parts of making a decision to delay/skip F31 is figuring out, ahead of the decision, what the expected experience is for users and packagers. Does F30 have normal stability, or do we try to keep users happy by moving things forward with ad-hoc updates and cross-our-fingers and hope nothing breaks?

I tend to think about this in terms of GNOME - would we rebase to GNOME 3.34 in the middle of F30 or not? But there's a lot of other pieces of software where similar considerations apply: container tools, cockpit, NetworkManager, etc.

And if we did do updates like that, would we consider respinning media and making a "F30.1"?

That would defeat a very large chunk of the purpose of delaying the release, as it'd require pretty much a full cycle of work from all the folks involved in releases. Maybe it'd theoretically involve *slightly* less firefighting, but we'd still have to jump through all the hoops of release candidates and blocker review and mirror syncing and all that jazz.