From 4bf4d832f130d5edefd3694ead67eb209652fcc9 Mon Sep 17 00:00:00 2001 From: jbtrystram Date: Wed, 22 May 2024 10:45:44 +0200 Subject: [PATCH] Docs: scrub bodhi-updates references We are not using the bodhi-updates streams, remove it from the docs See https://github.com/coreos/fedora-coreos-tracker/issues/1734 --- Design.md | 12 ++++-------- stream-tooling.md | 8 ++------ 2 files changed, 6 insertions(+), 14 deletions(-) diff --git a/Design.md b/Design.md index 71add3d..c458776 100644 --- a/Design.md +++ b/Design.md @@ -18,7 +18,7 @@ conclusion should be summarized here with a link to the issue. ## OSTree Delivery Format -- Originally discussed in issue [#23](https://github.com/coreos/fedora-coreos-tracker/issues/23). +- Originally discussed in issue [#23](https://github.com/coreos/fedora-coreos-tracker/issues/23). ### Summary: @@ -29,7 +29,7 @@ end user systems: repo) on a server and fetched via HTTP requests. - rojig: uses a special rojig RPM and re-assembles OSTree commit from RPMs already on mirrors. -- OCI: OSTree commits are packaged up in OCI container images and delivered +- OCI: OSTree commits are packaged up in OCI container images and delivered via a container registry. Currently the plan in Fedora CoreOS is to deliver content via a plain @@ -102,7 +102,7 @@ Because production refs are unversioned, users will seamlessly upgrade between F ## Disk Layout -- Originally discussed in issue [#18](https://github.com/coreos/fedora-coreos-tracker/issues/18). +- Originally discussed in issue [#18](https://github.com/coreos/fedora-coreos-tracker/issues/18). See also [dustymabe's comment](https://github.com/coreos/fedora-coreos-tracker/issues/18#issuecomment-409668929) summarizing the discussion in the FCOS meeting. - Filesystem details were discussed in [#33](https://github.com/coreos/fedora-coreos-tracker/issues/33). @@ -228,7 +228,7 @@ Originally discussed in [#71](https://github.com/coreos/fedora-coreos-tracker/is Originally discussed in [#68](https://github.com/coreos/fedora-coreos-tracker/issues/68). - OpenStack environments do not require a cloud agent -- We will provide any base level of functionality with ignition and coreos-metadata +- We will provide any base level of functionality with ignition and coreos-metadata ### Packet: @@ -345,8 +345,6 @@ next-devel | 10 testing-devel | 20 rawhide | 91 branched | 92 -bodhi-updates-testing | 93 -bodhi-updates | 94 For developer builds (those not produced by the official pipeline), Z is always `dev`. @@ -365,8 +363,6 @@ next-devel | 31.20191018.10.10 | 11th build of the day testing-devel | 31.20191018.20.0 | rawhide | 33.20191018.91.0 | F33-based, first build of the day branched | 32.20191018.92.0 | -bodhi-updates-testing | 31.20191018.93.0 | -bodhi-updates | 31.20191018.94.0 | (any developer build) | 31.20191018.dev.2 | Third build of the day We are not committing to this version scheme indefinitely, and may change it in future if it proves unworkable. A new Fedora major release (X bump) would be a good time to make such a change. We don't intend Fedora CoreOS version numbers to be parsed by machine; they're meant to help humans quickly determine the salient properties of a release. diff --git a/stream-tooling.md b/stream-tooling.md index c0e1a06..f8455b8 100644 --- a/stream-tooling.md +++ b/stream-tooling.md @@ -13,8 +13,6 @@ FCOS will have multiple streams: | Development | next-devel | annex | | Mechanical | rawhide | annex | | Mechanical | branched | annex | -| Mechanical | bodhi-updates | annex | -| Mechanical | bodhi-updates-testing | annex | Development and mechanical streams are subject to change. @@ -32,8 +30,6 @@ We need a way to both (1) fix the content set for a particular stream release, a **Mechanical** streams are not curated; they're automated nightly snapshots of the underlying repos. They source their RPMs from the regular Fedora repos (using 30 here to mean `$currentrelease`): 1. **rawhide** <- f32 2. **branched** <- f31 when a branch exists, otherwise tracks **rawhide** -3. **bodhi-updates** <- f30-stable + f30-updates -4. **bodhi-updates-testing** <- f30-stable + f30-updates + f30-updates-testing **Production** streams are intended for production use. They source their RPMs from a _single_ Koji tag, `coreos-pool`, from which we create a yum repo: 1. **next** <- coreos-pool @@ -52,7 +48,7 @@ There is also a second Koji tag, `coreos-release`, for packages which have been We maintain a git repository containing the rpm-ostree treefile and lockfiles. This could be [fedora-coreos-config](https://github.com/coreos/fedora-coreos-config). We have one branch for each stream, and no main branch. -For the mechanical streams, a nightly job will run the compose from the corresponding yum repos and SCM refs. This job will output a lockfile for each CPU architecture. Those lockfiles will be committed to Git to preserve a record of the build's contents, and the builds will be pushed to the corresponding ostree refs. The {bodhi-updates, branched} lockfile will also be PR'd to the {testing-devel, next-devel} branch, the latter only during the part of the cycle where next-devel is maintained. We want to keep the development branches ready to release, so those PRs are not merged unless green. +For the mechanical streams, a nightly job will run the compose from the corresponding yum repos and SCM refs. This job will output a lockfile for each CPU architecture. Those lockfiles will be committed to Git to preserve a record of the build's contents, and the builds will be pushed to the corresponding ostree refs. The branched lockfile will also be PR'd to the {testing-devel, next-devel} branch, the latter only during the part of the cycle where next-devel is maintained. We want to keep the development branches ready to release, so those PRs are not merged unless green. The lockfiles produced from the automatic snapshot will never be hand-modified, and in the next/testing/stable branches will never be modified at all except during promotions. Instead, pins (to older NEVRAs) and updates (to newer ones) will be hand-maintained in the Git branches in a separate lockfile that overrides the autogenerated ones. These overrides will be the major distinction between the mechanical refs and the "curated" (development/production) refs. Each curated branch will have one override file, which can carry both CPU-architecture-independent and architecture-specific overrides. @@ -74,7 +70,7 @@ Update the development treefile as usual. On the next bot push, the lockfile wil To focus development effort, there will be one base treefile shared across all branches, whose canonical copy will live in the testing-devel branch. Changes will automatically be mirrored to next-devel and to the mechanical branches. To address divergence across Fedora releases, each branch will also have an overlay treefile (possibly empty): -- **testing-devel** -> automatically mirrored to bodhi-updates and bodhi-updates-testing +- **testing-devel** - **next-devel** -> automatically mirrored to branched - **rawhide**