https://fedoraproject.org/wiki/Changes/Freeze_after_branching_until_compose_is_ready == 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: jkonecny@xxxxxxxxxx * Name: [[User:churchyard| Miro Hrončok]] * Email: mhroncok@xxxxxxxxxx * Name: [[User:Kevin| Kevin Fenzi]] (nirik) * Email: kevin@xxxxxxxxx == 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: [https://pagure.io/releng/issue/9014 #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 == 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. == Documentation == Mailing thread https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/QXTZIAHCPCCVWCGKFG6NYYN6ODAOFZ6D/#QXTZIAHCPCCVWCGKFG6NYYN6ODAOFZ6D -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
