On Thu, Jul 06, 2017 at 09:15:20PM -0400, Matthew Miller wrote:
Unless we want to have very soft release criteria and ship stuff we
know to be broken (or suspect but haven't completely checked out), we
need changes after we branch (and especially after the beta is
released) to follow the stable releases updates policy --
way, we have a fighting chance of identifying blockers with enough time
to get resources directed to fix them without indefinite delay.
And, actually, having thought about this overnight :), I'd like to make
this stronger. In the period between the Beta Release and the Final
Freeze, updates are accepted through Bodhi, but *please*:
1. As above, please note that Stable Releases Updates Policy _applies
at Beta_. This is *not* a policy change: see
2. Weigh how important it is to get the update in for the release
vs. a) waiting to be an update later or b) waiting for the next
release entirely. Think: If this *were* a freeze, would I file for a
Freeze Exception? If you have a new version of software you want to
get to users early, consider making a Copr (or for Server now, a
3. If you have a big thing you know will land during the Beta period,
please consider filing a Change so it can be tracked — and note the
timing in the Change details.
4. If you do make an update and push it to stable, please test any
release criteria which might be impacted by your update and file
Blocker bugs if necessary. We can't just leave this for QA. I'm sure
the QA team will be happy to help, but you know your change better
than they do and you're in a better position to fix any problems.
You should be able to find a nightly compose at
5. If you work on a Spin or are in an Edition WG that has a release
deliverable, please take note of incoming changes which might affect
that deliverable and help keep the nightly test matrices up to date.
Fedora Project Leader