Docs: scrub bodhi-updates references

We are not using the bodhi-updates streams, remove it from the docs
See #1734

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.

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**