Fedora 32 System-Wide Change proposal: Freeze after branching until compose is ready

<a href="" title=""></a>

== Summary ==
Add freeze (similar to [[Milestone_freezes|beta or final freeze]])
after new Fedora is branched. This freeze will be removed as soon as a
branched compose is ready.

== Owner ==
* Name: [[User:jkonecny| Jiří Konečný]]
* Email: <a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>
* Name: [[User:churchyard| Miro Hrončok]]
* Email: <a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>
* Name: [[User:Kevin| Kevin Fenzi]] (nirik)
* Email: <a href="mailto: ... at scrye dot com"> ... at scrye dot com</a>

== Detailed Description ==
For basically every branching of Fedora there is a gap between the
branching date and when the first branched compose is created. This
gap is most of the time not that problematic because it's just a few
days but it could be a lot longer given bad circumstances. For Fedora
31, the first branched compose was available only a week before the
beta freeze.

Having a finished compose late introduces a plenty of problems for
projects which need to test on the newer compose. Not having the
compose will result in testing in Rawhide, however the longer is the
gap between branching and compose the more diverged Rawhide and
branched Fedora are. Package updates are not available on branched
before a compose is ready.

For example, in case of Fedora 31 branching Rawhide (Fedora 32)
adapted a new Python version sooner than the compose for the Fedora 31
was available. So tests were running with the new Python version
showing errors not related to the branched Fedora.

This change will help to avoid problems described above in the future
for new branched Fedoras. It will help Release Engineering to
concentrate on issues blocking compose and avoid having to solve new
problems introduced by package updates.

== Benefit to Fedora ==
This change should help to make the gap between branching date and
when the compose is ready shorter. It should help teams to stay
focused on fixing the compose instead of making new features.

== Scope ==
* Proposal owners: Create a wiki page describing this freeze
* Other developers: Release Engineers have to create and/or adjust
koji targets and tags after branching. They will make the adjustments,
but disable some part of the workflow. Either collect packages in the
tag to be signed, or collect them in the tag to be autosubmitted to
gating by bodhi. Then, once a compose is done, restart that process
and process the backlog. If a package is needed for a fix, it can
manually be tagged in.

* Release engineering: [ #9014]
* Policies and guidelines: Fedora wiki page about freeze process
should change appropriately.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

== How To Test ==
After Fedora is branched, new package updates are not getting into
compose if not tagged by Release Engineers explicitly, until a compose
is finished.

== User Experience ==
Users should have compose of the branched Fedora sooner. This also
makes package updates sooner to land.

== Dependencies ==

== Contingency Plan ==
* Contingency mechanism: Release Engineering will use the old stable
steps used for older Fedoras.
* Contingency deadline: Decision of Release Engineering.

== Documentation ==
Mailing thread <a href=" ... at lists dot" title=" ... at lists dot"> ... at lists dot fedoraproject....</a>


Re: Fedora 32 System-Wide Change proposal: Freeze after branchin

By Ben Cotton at 11/14/2019 - 08:43

If this change is approved, I'll create a 4-day (Tue–Fri) freeze on
the release schedule labeled "Branch freeze (end date approximate)" or
something to that effect. This way it will be visible, but will also
indicate that the freeze may be longer or shorter than the advertised