From 997bd212d760f223ecaa98cbc5e020ad35754b01 Mon Sep 17 00:00:00 2001 From: Kevin Fenzi Date: Jan 02 2021 19:40:52 +0000 Subject: Update the updates policy document * Drop references to Alpha (we no longer have an Alpha) * Drop references to taskotron (it has been retired) * Consolidate some things as common to all branches. * Reword things where we didn't use to have bodhi enabled (But now it is all the time everywhere). * Mention side-tags in several more places * Drop "Bodhi enablement" Since we always have bodhi enabled. * Add references to "Base Critera" for rawhide/branched composes. * Try to note when bodhi automatically makes an update and when maintainers have to do so themselves. * Added fedora-ci and openqa links/sections. CHANGE: allow releng to untag things from rawhide in exceptional situations (left up to releng). (ie, needs fesco ratification) Signed-off-by: Kevin Fenzi --- diff --git a/fesco/modules/ROOT/pages/Updates_Policy.adoc b/fesco/modules/ROOT/pages/Updates_Policy.adoc index 5cdea8b..7895442 100644 --- a/fesco/modules/ROOT/pages/Updates_Policy.adoc +++ b/fesco/modules/ROOT/pages/Updates_Policy.adoc @@ -15,11 +15,39 @@ link:https://fedoraproject.org/wiki/Package_update_HOWTO[Package update HOWTO] f pushing the updates. The link:https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release Life Cycle] provides a more detailed overview of the development process. +== Common updates requirements for all Fedora releases + +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 +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]. +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] + +[[consumable-updates]] +=== Consumable updates + +All updates MUST be ready for consumption in the Fedora release their bodhi update is created for. +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. + == Rawhide / devel / master 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). +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 +successfull compose so maintainers can integrate their changes with everyone else. Repos available: link:https://fedoraproject.org/wiki/Repositories#rawhide[_rawhide_] @@ -34,20 +62,30 @@ 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 +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: -* Try not to push a broken build (breaks the default buildroot package set, etc.). +* 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. * 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) whose packages depend on yours to rebuild or offer to do these rebuilds for them. -* Use a separate buildsystem tag when dealing with mass builds of many packages, so they can land at - the same time. File a link:https://pagure.io/releng/new_issue[rel-eng ticket] for this. +* Use a side tag tag when dealing with mass builds of many packages, so they can land at + the same time. See + link:https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/[Rawhide Gating/multi-builds] * Feel free to push out the newest version of packages as long as they do not cause breakage. Also keep in mind when the next Fedora release will be branched off, and be fairly confident that there will be a stable enough release in time for the next Fedora release. Otherwise you may have to 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. * 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. @@ -58,51 +96,61 @@ For updates to rawhide packages, Maintainers SHOULD: A link:https://fedoraproject.org/wiki/Releases/Branched[Branched] release exists for part of the development cycle. It is branched off Rawhide and eventually becomes the next stable release. -After the <> point, Branched releases do use the update feedback system (Bodhi). +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 +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). + There are several "phases" that a branched release goes through that affect what updates can and should be done. In general maintainers should keep in mind that this tree is being used to stabilize for the next release, so changes should be careful and considered and heading toward stability. -[[branched-pre-bodhi-enabling]] -=== https://fedoraproject.org/wiki/Releases/Branched[Branched], pre-Bodhi enabling +[[post-branch-freeze]] +=== 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 +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 +ready for them. + +[[pre-beta-freeze]] +=== https://fedoraproject.org/wiki/Releases/Branched[Branched], pre-beta-freeze For a short time after link:https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[the branch event -happens] but before the <> point, the Branched release works exactly like Rawhide: +happens] but before the <> point the Branched release works like Rawhide: builds submitted by packagers are considered -link:https://fedoraproject.org/wiki/Repositories#stable[stable] immediately, and sent to the +link:https://fedoraproject.org/wiki/Repositories#stable[stable] after passing through any gating tests +via a bodhi update, and are sent to the link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_ repository] directly in the next nightly compose. There are no restrictions beyond those for Rawhide at this point, but maintainers *SHOULD* be thinking about stabilization from this point onward, and making sure their packages will be in good -condition well in advance of the stable release. Some packages will be signed at this point, but not -all of them. You may have to use `--nogpgcheck` to install or update. +condition well in advance of the stable release. Repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] -[[bodhi-enabling]] -=== Bodhi enabling +[[beta-freeze]] [[bodhi-change-point]] +=== beta-freeze and bodhi-change-point -At the _Bodhi enabling point_, the Bodhi update system is enabled for the Branched release. After -this point *for the entire remaining lifetime of the release*, all updates must go through Bodhi -before they can be marked _stable_ and moved to either -link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] or -link:https://fedoraproject.org/wiki/Repositories#updates[_updates_]. -At present, the _Bodhi enabling point_ occurs on the day of the -link:https://fedoraproject.org/wiki/Milestone_freezes[Beta freeze], -but it is important to remember that they are distinct events: -the Beta freeze lasts until Beta release, but Bodhi enabling is permanent. +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 +by maintainers instead of automatically being created and checked only against gating tests. +Updates now pass through updates-testing to allow for user feedback. Repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_], link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_] -At this point all packages will be signed and gpgcheck should be enabled for all installs/updates. - [[pre-beta]] === Pre Beta -This is the time between the <> point and the Beta release. During this time we are +This is the time between the <> point and the Beta release. During this time we are attempting to stabilize the major versions of software that will be shipped with the final release of the OS. Major updates can be tolerated, but breaking things for early testers should be avoided -if possible. Additionally, as we get close to Alpha or Beta releases any change that breaks composes +if possible. Additionally, as we get close to Beta or Final releases any change that breaks composes of Live media, install media or testing should be avoided. Packages for Changes should be landing and getting major testing. @@ -131,7 +179,7 @@ and Maintainers *SHOULD* (not enforced): ==== Milestone freezes During this period there are two link:https://fedoraproject.org/wiki/Milestone_freezes[Milestone freezes], -_Alpha freeze_ and _Beta freeze_. Each is scheduled to run for the two weeks leading up to +_Beta freeze_ and _Final freeze_. Each is scheduled to run for the three weeks leading up to the release date (and in fact lasts until the release is signed off, even if it is delayed). During these times, builds will not be marked _stable_ and moved from link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_] to @@ -470,48 +518,14 @@ link:https://fedoraproject.org/wiki/Updates_Lessons[Updates Lessons]. FESCo will work with QA and others to prevent or mitigate the issue. -[[updating-inter-dependent-packages]] -== Updating inter-dependent packages +[[bodhi]] +All updates to any Fedora pass though the link:https://bodhi.fedoraproject.org updates application. -When one updated package requires another (or more than one other), 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]. +[[openqa]] +link:https://openqa.fedoraproject.org[OpenQA] tests critpath updates in stable releases and compose artifacts +for rawhide/branched composes/release candidates. -[[taskotron]] -== Taskotron - -The Taskotron automated testing system runs two tests against all updates submitted to Bodhi: a -dependency check (to ensure all dependencies of the package(s) can be fulfilled from the -repositories) and an upgrade path check (to ensure the update does not break the upgrade path from -release to release, i.e. that the update does not contain a package versioned higher than the newest -version of the same package available in a later Fedora release). Taskotron adds comments to Bodhi -with the results of these test runs. Failing either test will disable -link:https://fedoraproject.org/wiki/Bodhi#Karma_Automatism[Bodhi karma automatism] for -the update (if it was enabled). If you submit an update that fails one of these -tests, please check the result and fix the problem. If you are sure there is an error in the -test rather than an error in your package, you may still manually push the update or re-enable karma -automatism. - -Previously, the old AutoQA system ran similar checks to Taskotron. -The scope of these automated checks is expected to expand in future. -The link:https://fedoraproject.org/wiki/QA:Package_Update_Acceptance_Test_Plan[Package Update Acceptance Test Plan] -was written as the original plan for AutoQA update validation, -and may still be seen as a framework for future work on Taskotron. - -[[bodhi-use]] -== Bodhi Use - -Bodhi is meant as the method for getting updates into an existing release or pre-release. It does -provide a testing mechanism to make sure that nothing unforeseen will arise, but the expectation is -that packages submitted are likely ready to ship as an update. As such, any packages submitted to -Bodhi must be done with the intent that the package submitted is ready for general consumption. The -users kind enough to test these packages have come to expect this, and doing anything else moves -against their good will, and is likely to drive testers away. Bodhi and updates-testing are not a -place for experimentation or advanced notification of potentially disruptive updates. These should -be handled with packages in link:https://copr.fedorainfracloud.org/[Copr] or another public repository -with a message to call for testing on the appropriate mailing lists. +[[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 +from going stable.