From 39705cbafa3f46df18d323fc0b840864a0be57f0 Mon Sep 17 00:00:00 2001 From: Kevin Fenzi Date: Jan 02 2021 19:41:10 +0000 Subject: Changes from pr review Signed-off-by: Kevin Fenzi --- diff --git a/fesco/modules/ROOT/pages/Updates_Policy.adoc b/fesco/modules/ROOT/pages/Updates_Policy.adoc index 7895442..ac1c231 100644 --- a/fesco/modules/ROOT/pages/Updates_Policy.adoc +++ b/fesco/modules/ROOT/pages/Updates_Policy.adoc @@ -22,21 +22,21 @@ Some critera applies to any update to any fedora branch/release: [[updating-inter-dependent-packages]] === Updating inter-dependent packages -When one updated package requires another (or more than one other), the packages should be submitted +When one updated package requires one or more other packages, the packages should be submitted together as a single update. For instance, if package A depends on packages B and C, and you want to update to a new version of package A which requires new versions of B and C, you must submit a single update containing the updated versions of all three packages. It is a bad idea to submit three separate updates, because if the update for package A is pushed stable before the updates for packages B and C, it will cause dependency problems. There is information on how to submit multi-package updates in the -link:https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages[package update HOWTO]. +link:https://fedoraproject.org/wiki/Package_update_HOWTO#Updating_inter-dependent_packages[package update HOWTO] and information about using side-tags for multiple updates in -link:https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/[Rawhide Gating/multi-builds] +link:https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/[Rawhide Gating/multi-builds]. [[consumable-updates]] === Consumable updates -All updates MUST be ready for consumption in the Fedora release their bodhi update is created for. +Bodhi updates should only be created for builds which are expected to qualify for being pushed to stable. Maintainers should not use bodhi's testing states to test updates they never intend to push stable. This sort of testing should be done in link:https://copr.fedorainfracloud.org/[Copr] or other seperate public repositories. Consult with the QA team for further testing assistance. @@ -45,8 +45,8 @@ seperate public repositories. Consult with the QA team for further testing assis link:https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide] is the always-rolling development tree. Package updates built for rawhide are composed every day and pushed out to all rawhide consumers. New builds against -this tree also are added to the build root (ie, other packages build from them). It's intended that this tree -meets the link:https://fedoraproject.org/wiki/Basic_Release_Criteria[Basic Release Critera] for any +this tree also are added to the build root (ie, other packages build from them). This tree +is intended to meet the link:https://fedoraproject.org/wiki/Basic_Release_Criteria[Basic Release Critera] for any successfull compose so maintainers can integrate their changes with everyone else. Repos available: link:https://fedoraproject.org/wiki/Repositories#rawhide[_rawhide_] @@ -62,14 +62,14 @@ Currently the default gating policy is empty, thus Fedora Rawhide update can pas results. Package maintainer can opt-in for the gating of a package, by setting up individual gating policies, see link:https://docs.fedoraproject.org/en-US/rawhide-gating/optin/[Rawhide Gating/optin]. -As soon as a build is completed, a bodhi update is automatically created and the update is used to +As soon as a build is completed, a bodhi update is automatically created. The update is used to show test results. If gating tests pass, the update is marked stable after a few minutes, pushed stable and will be added to the next nightly compose. -For updates to rawhide packages, Maintainers SHOULD: +For updates to rawhide packages, Maintainers MUST: -* Try not to push a broken build (breaks the default buildroot package set, etc.). This causes additional work - for other maintainers trying to integrate their changes. +* not push any known broken builds (breaks the default buildroot package set, etc.). + This causes additional work for other maintainers trying to integrate their changes. * When a proposed update contains an ABI or API change: notify *a week in advance* both the link:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel list] and maintainers directly (using the ``_packagename_-\owner@fedoraproject.org`` alias) @@ -83,9 +83,8 @@ For updates to rawhide packages, Maintainers SHOULD: back down to an older, stable version after the branching, which may involve epochs and other inconveniences. * Once a package has been added to the compose and that compose has finished and synced to the master - mirrors, it will normally not be untagged. This is to prevent others from being able to depend on - changes once they have happened. In exceptional cases, releng may untag packages, but this will - be a last resort. + mirrors, it will normally not be untagged. This is required to allow others to depend on the + build once it has become visible. In exceptional cases, releng may untag packages. * If approved by FESCo, push pre-release versions of low level packages. FESCo approves certain packages, including (but not limited to) ``glibc`` and ``gcc``, to provide pre-release versions here. @@ -100,7 +99,7 @@ All successfull branched composes should meet the link:https://fedoraproject.org/wiki/Basic_Release_Criteria[Basic Release Critera] Branched releases do use the update feedback system (Bodhi): At first just like rawhide (updates are -automatically created when a build finishes, tests run and automatically pushed to include in the next +automatically created when a build finishes, tests run and builds are automatically pushed into the next compose), but then at Beta Freeze they switch to using it as stable releases do (maintainers must create updates and submit them for testing, etc). @@ -112,7 +111,7 @@ for the next release, so changes should be careful and considered and heading to === https://fedoraproject.org/wiki/Releases/Branched[Branched], post-branch-freeze Once the new release is branched off rawhide, the updates flow through bodhi is stopped until -there is a successfull branched compose. This period usually lasts just a few days. Release +there has been a successful branched compose. This period usually lasts just a few days. Release engineering may pass some updates to stable to get the compose to complete, but otherwise all updates are stopped until this initial branched compose is completed. This is to make sure we have a compose to build on and aren't dealing with problems landing in new updates before we are @@ -137,7 +136,7 @@ Repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora === beta-freeze and bodhi-change-point At the <> point, the Bodhi update system is changed for the branched release to behave -as it does for stable releases (below) instead of rawhide. That is, updates are manually created +as it does for stable releases (see below) instead of rawhide. That is, updates are manually created by maintainers instead of automatically being created and checked only against gating tests. Updates now pass through updates-testing to allow for user feedback. @@ -516,8 +515,6 @@ serious problem for Fedora users, please file a link:https://pagure.io/fesco/new work to prevent the issue from happening again. A past record of such issues can be found at link:https://fedoraproject.org/wiki/Updates_Lessons[Updates Lessons]. -FESCo will work with QA and others to prevent or mitigate the issue. - [[bodhi]] All updates to any Fedora pass though the link:https://bodhi.fedoraproject.org updates application. @@ -527,5 +524,5 @@ for rawhide/branched composes/release candidates. [[fedora-ci]] link:https://docs.fedoraproject.org/en-US/ci/[Fedora CI] runs tests on all bodhi updates. If package -maintainers have indicated that some of these tests block release, the bodhi update will be blocked +maintainers have marked the tests as blocking, the bodhi update will be blocked from going stable.