From Fedora Project Wiki
< Changes
(Create first version) |
Churchyard (talk | contribs) mNo edit summary |
||
| Line 24: | Line 24: | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. | ||
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". --> | Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". --> | ||
Add freeze (similar to [[Milestone_freezes|beta or final freeze]]) after new Fedora is branched. This freeze will be removed as soon as compose | 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 == | == Owner == | ||
| Line 61: | Line 61: | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
For basically every branching of Fedora there is a gap between the branching date and when the first 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 compose was available only a week before beta freeze. | 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 compose late | 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 | 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. | 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. | ||
| Line 105: | Line 105: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Other developers: Release Engineers have to create 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. | * 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. | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 141: | Line 141: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
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 == | == User Experience == | ||
Revision as of 13:48, 13 November 2019
Freeze after branching until compose is ready
Summary
Add freeze (similar to beta or final freeze) after new Fedora is branched. This freeze will be removed as soon as a branched compose is ready.
Owner
- Name: Jiří Konečný
- Email: jkonecny@redhat.com
- Name: Miro Hrončok
- Email: mhroncok@redhat.com
Current status
- Targeted release: Fedora 32
- Last updated: 2019-11-13
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
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 gab 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: #Releng issue number (a check of an impact with Release Engineering is needed)
- Policies and guidelines: Fedora wiki page about freeze process should change appropriately.
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
N/A
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
N/A
Contingency Plan
- Contingency mechanism: Release Engineering will use the old stable steps used for older Fedoras.
- Contingency deadline: Decision of Release Engineering.
- Blocks release? No
- Blocks product? No