From Fedora Project Wiki

(Redirected from Change deadlines)

Milestone freezes happen two weeks before the public release of each Fedora Beta and Final release. Milestone freeze is the generic term. The specific milestone freezes are the Beta freeze and Final freeze.

What happens in a Milestone freeze?

Historical names
Between Fedora 14 Beta and Fedora 21 Alpha, these were known as Change deadlines.[1] Prior to Fedora 14 Beta, they were again called Alpha freeze, Beta freeze and Final freeze. At earlier times when the milestone names were different, the freeze names naturally corresponded. The Alpha milestone (and hence the Alpha freeze) ceased to exist with the No More Alpha Change in the Fedora 27 release.

At the milestone freeze, pushes[2] from the updates-testing repository to the stable fedora repository for the pending Branched release are suspended until the release candidate is accepted.

What repositories and releases does a milestone freeze affect?

The freeze applies only to Branched (the pending pre-release), and only to the stable fedora repository. Packages can still be submitted to updates-testing in the usual manner, and other releases are not affected at all.

When does each milestone freeze end?

Each milestone freeze ends shortly after the milestone release is approved for release at a Go No Go Meeting. After the Beta release, the fedora repository is once more opened to stable pushes under the Updates Policy. Packages marked as stable through the usual Bodhi process between Beta release and Final freeze will appear in the Final release.

What happens to updates that go stable after the Final freeze?

Once the Final freeze takes effect, the release package set is decided except for blocker and freeze exception bug fixes. There is no further window for other packages to appear in the Final release per se. Other updates submitted for stable status during this period are queued and, once the Final release is approved, are pushed not to the fedora repository but to the updates repository.

Packages that meet the requirements for stable status between Final freeze and Final release day will appear in the updates repository on the day of release. Such packages are sometimes referred to as 0-day updates.

How are freeze exceptions proposed and granted?

Exceptions to the milestone freezes are granted only through the blocker and freeze exception policies, to packages that fix accepted blocker or accepted freeze exception bugs. If you believe a build should be except from a Milestone freeze, please refer to these pages for details on how and when to propose a bug for blocker or freeze exception status.

How do milestone freezes relate to Changes?

The Changes process for tracking major Fedora development work and the milestone freezes are not inherently related. The reason for milestone freezes is to reduce "churn" in the stable package set from which a milestone is being composed in order to make the release compose and validation processes manageable. The need for these freezes arises regardless of other details of the development process.

However, the nature of a milestone freeze makes it natural for some Change policy dates to coincide with them. Change development work will not usually qualify for a freeze exception, so if a Change is expected to reach a certain level of quality by the release of a particular milestone, it is effectively the case that it must reach that level of quality by the freeze date for that milestone.

For this reason, the Changes Checkpoint #3 date occurs on the same day as the Beta freeze.

Where can I find the rules for updates outside of milestone freezes?

The policy for pushes from updates-testing to fedora for Branched releases outside of the Milestone freezes is the Updates Policy.

Where can I find an overview of the full development process?

The Fedora Release Life Cycle provides a good overview and a handy jumping-off point for more details on the complete Fedora release process.

  1. See the 2010-05-18 FESCo meeting for the decision to change the name to Change deadline, and this 2014-09 mailing list thread for the decision to change it back.
  2. A push is a release engineering term for moving a package into a particular repository of packages.