Documentation/releases: Update checklist

Having the release notes mostly ready one week before the release
allows for better review.

Some statistics, the actual release date and commit ID can only be
filled in on release day, but there's a tried & true technique for
that: placeholders.

It's also a nice touch to have the release notes of a release within
its source tarballs, so push them right before creating the release
(since changes in Documentation/releases won't break coreboot in
any way).

Change-Id: Iad7ba1ba4fc841bf437f2a997428b7f636e15422
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36957
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit is contained in:
Patrick Georgi 2019-11-19 17:15:31 +01:00
parent 85678b8419
commit eb80e053b6
1 changed files with 3 additions and 2 deletions

View File

@ -56,17 +56,18 @@ be more frequent than was needed, so we scaled it back to twice a year.
and to update the release notes
- [ ] Update the topic in the irc channel with the date of the upcoming
release
- [ ] Finalize release notes (as much as possible), without specifying
release commit ids
### Day of release
- [ ] Update release notes, without specifying release commit ids
- [ ] Select a commit ID to base the release upon, announce to IRC,
ask for testing.
- [ ] Test the commit selected for release
- [ ] Update release notes with actual commit id, push to repo
- [ ] Run release script
- [ ] Test the release from the actual release tarballs
- [ ] Push signed Tag to repo
- [ ] Announce that the release tag is done on IRC
- [ ] Update release notes with actual commit id, push to repo
- [ ] Upload release files to web server
- [ ] Upload crossgcc sources to web server
- [ ] Update download page to point to files, push to repo