Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

templates/rebase: more tweaks from current walk-through #1606

Merged
merged 3 commits into from
Nov 6, 2023
Merged

templates/rebase: more tweaks from current walk-through #1606

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9aed725
templates/rebase: mention that testing GA release is promoted from next
jlebon Nov 3, 2023
123a666
templates/rebase: clarify `testing` release staging
jlebon Nov 3, 2023
1298f76
templates/rebase: mention the final stable N-1 release
jlebon Nov 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 12 additions & 3 deletions .github/ISSUE_TEMPLATE/rebase.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,12 +70,19 @@ Branching is when a new stream is "branched" off of `rawhide`. This eventually b

## Preparing for Fedora (N) GA

Do these steps as soon as we have a Go confirmation for GA, usually the Thursday of the week before GA.

### Ship a final `next` release

If the packages in `next-devel` don't exactly match the last `next` release that was done, we need to do a release with the final GA content. This ensures that what we'll promote to `testing` has the exact content in GA (plus version fast-tracks). This usually happens on the Thursday of the announcement of Go.

- [ ] Ensure final `next` release has GA content

### Build rebased `testing` and final `stable` release on N-1

- [ ] Build `stable`; promote it from the `testing` branch, which should still be on N-1. Don't release it yet (i.e. don't run the `release` job).
- [ ] Build `testing`; promote it from the `next` branch instead of `testing-devel`. Don't release it yet (i.e. don't run the `release` job).

### Update [fedora-coreos-config](https://github.com/coreos/fedora-coreos-config/) `testing-devel`

- [ ] Bump `releasever` in `manifest.yaml`
Expand All @@ -87,12 +94,14 @@ If the packages in `next-devel` don't exactly match the last `next` release that

## At Fedora (N) GA

### Ship rebased `testing`
Do these steps on GA day.

### Release rebased `testing` and final `stable` release on N-1

- [ ] Ship `testing`
- [ ] Run the `release` job for the staged `testing` and `stable` builds and start rollout.
- [ ] Set a new update barrier for the final release of N-1 on `testing`. In the barrier entry set a link to [the docs](https://docs.fedoraproject.org/en-US/fedora-coreos/update-barrier-signing-keys/). See [discussion](https://github.com/coreos/fedora-coreos-tracker/issues/480#issuecomment-1247314065)

### Disable `next-devel` stream
### Disable `next-devel` stream if not needed

We prefer to disable `next-devel` when there is no difference between `testing-devel` and `next-devel`. This allows us to prevent wasting a bunch of resources (bandwidth, storage, compute) for no reason. After the switch to N if `next-devel` and `testing-devel` are in lockstep, then disable `next-devel`.

Expand Down
1 change: 1 addition & 0 deletions Design.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,6 +87,7 @@ The release process integrates with Fedora's release milestones in the following
- Week -1 (Fedora "Go" Decision): `next` release:
- `next` release with final Fedora GA content
- Week 0 (GA release): triple release:
- `stable` release promoted from previous `testing` (on N-1)
- `testing` release promoted from previous `next`
- `next` release contains latest Fedora N content, including Bodhi updates
- Week 2: triple release:
Expand Down