From 92f9ff5b7851773fc07b803561a6545ca52bebde Mon Sep 17 00:00:00 2001 From: Adam Williamson Date: Sep 21 2023 23:19:01 +0000 Subject: Substantially revise the release process guide This contained quite a lot of outdated information and steps that were duplicated with the SOPs. This revises it to focus on a full release cycle workflow, mainly linking out to the release step SOPs, with a few remaining notes that don't fit anywhere else kept at the bottom. Note this entirely drops the notification of release-blocking deliverables for a release - it was only done for F31 and F32, and nobody seems to be missing it. This also removes some duplication between the No-Go SOP and the Release Delay SOP and has a few other small updates and cleanups. Signed-off-by: Adam Williamson --- diff --git a/modules/ROOT/pages/pgm_guide/release_process.adoc b/modules/ROOT/pages/pgm_guide/release_process.adoc index 1d64143..d08d0a7 100644 --- a/modules/ROOT/pages/pgm_guide/release_process.adoc +++ b/modules/ROOT/pages/pgm_guide/release_process.adoc @@ -1,69 +1,39 @@ = Release Process This section covers program management information related to the process of getting a release out the door. -The table of contents below is organized by category. -The document beyond that is in chronological order. - -* *Meetings* -** xref:_gono_go_meeting[Go/No-Go meeting] -* *Bugzilla housekeeping* -** xref:_rawhide_rebase_warning[Rawhide rebase warning] -** xref:_branch_day[Branch day] -** xref:_release_day[Release day] -** xref:_eol_closure_reminder[EOL closure reminder] -** xref:_eol_day[EOL day] -* *Deliverables* -** xref:_release_blocking_deliverables[Release blocking deliverables] -** xref:_spins_keepalive[Spins keepalive] -* *Content* -** xref:_wiki_and_website_creation[Wiki and website creation] -** xref:_wiki_and_website_edits[Release day wiki and website edits] -** xref:_wiki_and_website_edits_2[EOL day wiki and website edits] +The document is in chronological order, referencing various SOPs, with small steps directly in-line, and notes below. TIP: You may choose to create a https://fedoraproject.org/wiki/Releases/31/HouseKeeping[wiki page] to track the status of housekeeping tasks, as has been done historically. -== Wiki and website creation - -There are so many places in the wiki to create things. -This is probably not an exhaustive list. -Hopefully in the future we'll have improved this process by consolidating and automating. - -* Update the index.html page on the https://fedorapeople.org/groups/schedule/[web view] of the schedule. -* Create a release page (`Releases/N`) in the wiki that collects the pages in that category. -You can use `{{Special:PrefixIndex/Releases/N/}}` to make it automagic (replacing "N" with the release number). -This is a good target for de-wikifying. -* Create a release schedule page (`Releases/N/Schedule`) in the wiki. -For Fedora 31 and previous, this included a manually-transcribed copy of key milestones. -For Fedora 32 and beyond, Ben decided that's a good way to introduce human error and made that page point to the https://fedorapeople.org/groups/schedule/[web view] of the schedule instead. -* Create a ChangeSet page (`Releases/N/ChangeSet`) in the wiki. -The output of the link:../changes#_create_tracking_bug[change processing scripts] gives you the content for this page. -* Create a Spins page (`Releases/N/Spins`) in the wiki. -Copy this from the previous version and make any changes as appropriate. -This is another good target for de-wikifying. -* Create a Release blocking deliverables page (`Releases/N/ReleaseBlocking`) in the wiki. -Again, copy this from the previous version and make changes as appropriate. -Stop me if you've heard this before, but this is a good target for de-wikifying. -* Add the new release to the xref:releases::index.adoc[Releases page] (or really, the `nav.adoc` sidebar). -* Add the new release to the https://fedoraproject.org/wiki/Changes[Changes wiki page]. -* Create a tracker bug for the release in Bugzilla. -This simplifies reporting and branching (particularly for Fedora N+2 proposals that come in before N+1 is branched) -** Use the **Changes Tracking** component -** Set the Alias to "FChanges" -** Add the **Tracking** keyword - -== Spins keepalive -xref:releases::spins/index.adoc[Solutions] (formerly Spins and Labs) are targeted showcases of Fedora Linux software. -As such, we want to make sure they're well-maintained. -To that end, https://pagure.io/fesco/issue/1972[FESCo approved a process] where the Program Manager checks with spin owners to make sure they're still around and wanting to produce the spin. -The deadline corresponds with the Self-Contained Change deadline. - -The process is defined in the xref:pgm_guide/sop/spins-keepalive.adoc[Spins keepalive SOP]. - -NOTE: You can be flexible with the deadline, as RelEng does not need much lead time to stop making something. - - -== Rawhide Rebase Warning -* Send the message below to devel-announce@lists.fedoraproject.org 1–3 weeks before the branch point. +== Workflow + +* New release (~1 year before target date) +** xref:pgm_guide/sop/release-new.adoc[New release SOP] +* Spin keepalive deadline (~3 weeks before Branch point) +** xref:pgm_guide/sop/spins-keepalive.adoc[Spins keepalive SOP] +* Rawhide rebase warning (1-3 weeks before Branch point) +** Send the xref:_rebase_warning_mail[rebase warning mail] to devel-announce@lists.fedoraproject.org, replacing +instances of "TKTK" appropriately +* Branch day +** xref:pgm_guide/sop/branch.adoc[Branching SOP] +** See xref:_bug_rebase_notes[notes on the bug rebase process] +* One week before each Go/No-Go meeting date +** Schedule and announce the meeting, or cancel it if the decision is clearly No-Go: +xref:pgm_guide/sop/go-nogo.adoc[Go/No-Go Meeting SOP] +* Go/No-Go meeting dates +** Run the meeting, following the xref:pgm_guide/sop/go-nogo.adoc[Go/No-Go Meeting SOP]. +See xref:gonogo_notes[Go/No-Go Meeting notes]. Follow up with the xref:pgm_guide/sop/release-go.adoc[Go] or xref:pgm_guide/sop/release-no_go.adoc[No-Go] SOP. +* Release day +** xref:pgm_guide/sop/release_day.adoc[Release day SOP] +* 2-14 days after release day +** Follow xref:pgm_guide/sop/eol-warning.adoc[EOL warning SOP] for the N-2 release +* Four weeks after release day +** Follow xref:pgm_guide/sop/eol-day.adoc[EOL day SOP] for the N-2 release + +== Rebase warning mail + +This is the email that should be sent out 1-3 weeks before the Branch point. The actual rebase +is covered in the xref:pgm_guide/sop/branch.adoc[Branching SOP]. .... Greetings, @@ -88,9 +58,7 @@ to help. The process was re-approved by FESCo https://pagure.io/fesco/issue/1096 . .... -== Branch day - -Most of the branching activity is done by Release Engineering, but the FPgM handles the Bugzilla changes. +== Bug rebase notes Bugs that meet all of the following conditions are branched from Rawhide to the newly-created version: @@ -105,37 +73,24 @@ Bugs that meet all of the following conditions are branched from Rawhide to the * the string ''RFE'' is '''not''' present in the summary * status != CLOSED -NOTE: According to jforbes, the reason we exclude kernel bugs is two-fold: +According to jforbes, the reason we exclude kernel bugs is two-fold: 1. A number of reported kernel bugs are longer-term issues that need to be solved over time, or bugs which upstream has to eventually get to. It has become the place to file these bugs, even if not against the rawhide kernel in specific so that they do not get auto closed in a year. 2. Rawhide kernels are most typically built as debug kernels only, and many bugs filed against them are not reproducible on branched non-debug kernels. -The process is defined in the xref:pgm_guide/sop/branch.adoc[Branching SOP]. - -== Release blocking deliverables -Some deliverables are release blockers — we do not ship the release if they are not successfully composed. -FESCo approved a https://pagure.io/fesco/issue/2108[proposal] to use a static list of release-blocking deliverables. -Formerly, this was a manual audit process each release. - -A week before the branch point, create the release-blocking page in the wiki (see https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking[the F31 page as an example]). -Email this to the devel mailing list. Any edits should have been included in Change proposals, but it's a good opportunity to catch anything that got overlooked. +== [[gonogo_notes]]Go/No-Go Meeting notes -== Go/No-Go meeting -Before each public release, FESCo, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. -This meeting is called the https://fedoraproject.org/wiki/Go_No_Go_Meeting[Go/No-Go Meeting]. -The Program Manager is responsible for scheduling and leading this important meeting. +The https://pagure.io/fedora-pgm/pgm_communication/blob/main/f/go_nogo.txt[meeting script] in the xref:pgm_guide/sop/go-nogo.adoc[Go/No-Go SOP] provides a general framework for running the Go/No-Go meeting. +The general flow is to verify that a compose is available, review blocker bugs, check that the test matrices are completed, and that CoreOS and IoT are ready. -==== During the meeting +The compose section is generally very quick. +Release Engineering or QA will confirm that a candidate compose exists. +If there is no candidate compose, skip straight to a "no-go" decision. -The https://pagure.io/fedora-pgm/pgm_communication/blob/main/f/go_nogo.txt[meeting script] in the xref:pgm_guide/sop/go-nogo.adoc[Go/No-Go SOP] provides a general framework for running the Go/No-Go meeting. -The general flow is to review blocker bugs, verify that a compose is available, and that the test matrices are completed. If there are proposed or accepted blocker bugs, the meeting becomes a blocker review meeting to evaluate them. This portion of the meeting can be led by a member of the QA team or by the Program Manager. It is not uncommon to defer some bugs until later in the meeting so that last-minute testing can be performed. -The compose section is generally very quick. -Release Engineering or QA will confirm that a candidate compose exists. - In the test matrices section, QA will review the results of tests. Some optional tests may not be complete. @@ -143,18 +98,3 @@ Finally, the Program Manager polls each of the constituent teams. If they all vote "go", then the release is "go" and will be released on the coming Tuesday. The Program Manager's work is done (at least as far as this goes). If the release is "no-go", then a follow-up meeting must happen. - - -== Release Day - -See xref:pgm_guide/sop/release_day.adoc[Release Day SOP]. - -== EOL Closure reminder - -The EOL closure reminder is posted to all bugs for Fedora N-2 after the GA date of a new release. -See the xref:pgm_guide/sop/eol-warning.adoc[EOL warning SOP] for the process. - - -== EOL day - -See the xref:pgm_guide/sop/eol-day.adoc[EOL day SOP] diff --git a/modules/ROOT/pages/pgm_guide/sop/release-new.adoc b/modules/ROOT/pages/pgm_guide/sop/release-new.adoc index 061cc74..b467f77 100644 --- a/modules/ROOT/pages/pgm_guide/sop/release-new.adoc +++ b/modules/ROOT/pages/pgm_guide/sop/release-new.adoc @@ -27,8 +27,12 @@ If a Change proposal is submitted for the release, that's a good time to start t .. Update the `:release-version:` macro in each adoc file .. Add listings to `nav.adoc` under the "Upcoming Releases" header. Copy the previous release's entries and update version numbers as appropriate. -. Create the `Releases/NN/ChangeSet` page on the wiki -.. Use the template below for guidance +. Update the schedule +.. Create a schedule for the new release, following the ../schedule[Schedule SOP] +.. Add the new release to the index.html page on the https://fedorapeople.org/groups/schedule/[web view] +of the schedule. +. Update the wiki Change pages for the new release +.. Create the `Releases/NN/ChangeSet` page on the wiki. Use the template below for guidance .Wiki template for ChangeSet page .... @@ -48,3 +52,4 @@ __TOC__ {{Anchor|accepted_self_contained}} == Fedora Linux NN Accepted Self-Contained Changes == .... +.. Add the new release to the https://fedoraproject.org/wiki/Changes[Changes wiki page] diff --git a/modules/ROOT/pages/pgm_guide/sop/release-no_go.adoc b/modules/ROOT/pages/pgm_guide/sop/release-no_go.adoc index 1362fba..6706d5d 100644 --- a/modules/ROOT/pages/pgm_guide/sop/release-no_go.adoc +++ b/modules/ROOT/pages/pgm_guide/sop/release-no_go.adoc @@ -2,33 +2,15 @@ == Trigger/timing -This document outlines the procedure for when a relase is declared "no-go". +This document outlines the procedure for when a release is declared "no-go". == Procedure -1. Shift to the next target milestone in the xref:pgm_guide/schedule.adoc[schedule]. -2. Update the dates in the xref:pgm_guide/pgm_communication.adoc#_fpgm_report[report] and xref:pgm_guide/pgm_communication.adoc#_fpgm_office_hours[office hours] files. -3. Send an announcement email similar to the below to logistics@lists.fedoraproject.org, devel-announce@lists.fedoraproject.org, test-announce@lists.fedoraproject.org, and rel-eng@lists.fedoraproject.org. -4. Cancel the go/no-go meeting if the "no-go" determination is made preemptively. +1. Follow the xref:pgm_guide/sop/release-delay.adoc[Release delay SOP]. +2. Cancel the go/no-go meeting if the "no-go" determination is made preemptively. For the Final milestone: 1. Submit a pull request to the release's https://src.fedoraproject.org/rpms/fedora-release[fedora-release package] to update the eol_date variable in the `fedora-release.spec` file. You may need to request a new package build from the Release Engineering team. 2. Update the release schedule's EOL date entry. - -=== No-go announcement email - -NOTE: The example below is based on the case where a release is preemptively declared "no go" due to oustanding blockers. - -[source] ----- -Due to outstanding blocker bugs[1], we do not have a current release candidate. As a result, Fedora Linux is NO-GO. - -The next Fedora Linux Go/No-Go meeting[2] will be held at 1700 UTC on Thursday in . We will aim for the milestone of . The release schedule[3] has been updated accordingly. - -[1] https://qa.fedoraproject.org/blockerbugs/milestone///buglist -[2] -[3] https://fedorapeople.org/groups/schedule/f-/f--key-tasks.html - -----