documentation/release: Update release checklist

Sync checklist with release template; add new heading for paragraph
on pushing the signed tag to make it stand out.

Change-Id: Id49b3f38d3501382b7fb7ac791190c0cacd58a11
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84034
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>

1 files changed, 35 insertions, 10 deletions

diff --git a/Documentation/releases/checklist.md b/Documentation/releases/checklist.md
index 29ebdbbbd4..641be993df 100644
--- a/Documentation/releases/checklist.md
+++ b/Documentation/releases/checklist.md
@@ -66,13 +66,23 @@ delayed, the next release will still be 3 months after the last release.
 
 ## Checklist
 
-### ~2 weeks prior to release
+### ~6 weeks prior to release
 - [ ] Announce upcoming release to mailing list, ask people to test and
       to update release notes.
 - [ ] Start marking patches that should to go into the release with a
-      tag "coreboot_release_X.yy"
+      tag "coreboot_release_X.yy".
+
+### ~4 weeks prior to release
+- [ ] Freeze toolchain state. Only relevant fixes are allowed from this point on.
+- [ ] Schedule release meetings.
+
+### ~2 weeks prior to release
+- [ ] Meet with release team.
+- [ ] Send reminder email to mailing list, ask for people to test, and to update the release notes.
+- [ ] Update the topic in the IRC channel with the date of the upcoming release.
 
 ### ~1 week prior to release
+- [ ] Meet with release team.
 - [ ] Send reminder email to mailing list, ask for people to test,
       and to update the release notes.
 - [ ] Update the topic in the IRC channel with the date of the upcoming
@@ -80,21 +90,22 @@ delayed, the next release will still be 3 months after the last release.
 - [ ] If there are any deprecations announced for the following release,
       make sure that a list of currently affected boards and chipsets is
       part of the release notes.
-- [ ] Finalize release notes as much as possible
-- [ ] Prepare release notes template for following release
-- [ ] Update `Documentation/releases/index.md`
+- [ ] Finalize release notes as much as possible.
+- [ ] Prepare release notes template for following release.
+- [ ] Update `Documentation/releases/index.md.
 - [ ] Check which branches need to be released. Any branch with changes
       should get a new release. Announce these branch releases and
       prepare release notes.
 
-### Day before release
+### Day before release tag
 - [ ] Make sure patches with tags for the release are merged.
 - [ ] Announce to IRC that the release will be tomorrow and ask for
       testing.
 - [ ] Run `util/vboot_list/vboot_list.sh` script to update the list of
       boards supported by vboot.
 
-### Day of release
+### Day of release tag
+- [ ] Meet with release team.
 - [ ] Review the full documentation about doing the release below.
 - [ ] Select a commit ID to base the release upon.
 - [ ] Test the commit selected for release.
@@ -120,11 +131,24 @@ delayed, the next release will still be 3 months after the last release.
       can be used as release builders.
 
 ### Week following the release
+- [ ] Do the final release notes - Fill in the release date, remove "Upcoming release"
+      and other filler from the current release notes.
+- [ ] ADMIN: Upload release files & toolchain tarballs to the web server.
+- [ ] ADMIN: Upload the final release notes to the web server.
+- [ ] ADMIN: Upload crossgcc sources to the web server.
+- [ ] Create coreboot-sdk and coreboot-jenkins-node docker images based on the release ID
+      and push them to dockerhub. These can be used as release builders.
 - [ ] Update download page to point to files, push to repo.
-- [ ] Write and publish blog post with release final notes. Branch
-      releases notes should be included in the same post.
 - [ ] Remove code that was announced it was going to be removed.
-- [ ] Update `Documentation/releases/boards_supported_on_branches.md`
+- [ ] Update AUTHORS file with any new authors.
+- [ ] Update Documentation/releases/boards_supported_on_branches.md.
+
+### 7 days after release tag
+- [ ] Meet with release team.
+- [ ] Write and publish blog post with release final notes. Branch releases notes (if any)
+      should be included in the same post.
+- [ ] Set up for next release.
+
 
 ### Creating a branch
 - [ ] Branches are named 4.xx_branch to differentiate from the tags.
@@ -230,6 +254,7 @@ commit db508565d2483394b709654c57533e55eebace51 (HEAD, tag: 4.6, origin/master,
 ...
 ````
 
+## Push the signed tag
 When you used the script to generate the release, a signed tag was
 generated in the tree that was downloaded. From the coreboot-X.Y tree,
 just run: `git push origin X.Y`. In case you pushed the wrong tag