Size: 10864
Comment: Copy / paste from the template
|
Size: 12053
Comment: release notes aligned with reports (not so many this release)
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
The following things need to be done for a release: |
The following things need to be done for the bullseye release: |
Line 8: | Line 7: |
At some point, we will have to tag the remaining RC bugs to filter what should be removed/deferred/fixed. It's possible to define our own sorting criteria by sending the following request to request@bugs.debian.org: | (./) At some point, we will have to tag the remaining RC bugs to filter what should be removed/deferred/fixed. It's possible to define our own sorting criteria by sending the following request to request@bugs.debian.org: |
Line 12: | Line 11: |
usercategory codename-sort * Codename [tag=] + Blockers for Codename [codename-is-blocker] + Planned for removal [codename-will-remove] + Ignored for Codename [codename-can-defer] |
usercategory bullseye-sort * bullseye [tag=] + Blockers for bullseye [bullseye-is-blocker] + Planned for removal [bullseye-will-remove] + Ignored for bullseye [bullseye-can-defer] |
Line 21: | Line 20: |
[[https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian.org@packages.debian.org;tag=codename-can-defer;tag=codename-will-remove;tag=codename-is-blocker;ordering=codename-sort]] | [[https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian.org@packages.debian.org;tag=bullseye-can-defer;tag=bullseye-will-remove;tag=bullseye-is-blocker;ordering=bullseye-sort]] |
Line 24: | Line 23: |
* [[https://bugs.debian.org/424427|#424427: [bts] should support usercategory]] | * [[DebianBug:424427|#424427: [bts] should support usercategory]] |
Line 29: | Line 28: |
* Decide on a code name for ''<codename>+2'' * Get that included in BTS tags: * @gTags in /srv/bugs.debian.org/etc/config on bugs-master.debian.org * bts_release_tags and bts_release_ignore_tags [[https://salsa.debian.org/webmaster-team/webwml/blob/master/english/Bugs/pkgreport-opts.inc|in webwml]] * Edit wiki pages to add the new release: ReleaseParty DebianReleases Debian<RELEASENAME> Debian<RELEASENAME-1> NewIn<RELEASENAME> Glossary * Edit/add deb.li pages to add the new release: relparty <RELEASENAME> get<RELEASENAME> * Theme (artwork) design should be finalised and decided * Prepare the website changes * Ensure that the following pages exist on debian.org/releases/<RELEASENAME> * index * credits * errata * installmanual (requires installmanual is being built for RELEASE as well) * releasenotes (requires releasenotes is being built for RELEASE as well) * reportingbugs * There should also be a page for debian.org/releases/<RELEASENAME+1> as there are some links to it. * The pages should say they are beta versions/not released etc. at this point * Assert the architecture list is up to date (release.data), new ports should be available on https://debian.org/ports (ports/index.wml) * Ensure that updates to the installation-guide appear on the website (d-i) [To avoid a repeat of <<mid(20170605233204.GB24136@mraw.org)>>] * Ensure that updates to the release-notes appear on the website * Decide on Release Architectures * Ensure image builds work for all release architectures * Generate and add release keys to debian-archive-keyring (see #860830 + #860831) * SRMs generate one (technically, RMs can generate it too, but SRMs will need it post release) * "reportbug ftp.debian.org" to get it added to https://ftp-master.debian.org/keys.html * FTP-masters generate several (see <<mid(878tlll6zo.fsf@deep-thought.43-1.org)>>) * Have FTP masters create security + backports archive for upcoming release * Re Announcements: Remember to clarify that -backports is a read-only to the sake of assisting with upgrades. * Remember to add the ACL to the new stable-backports and oldstable-backports-sloppy suites * Coordinate with security team to do a test upload to -security to check if it builds correctly everywhere * also do an upload of a package that needs signing * Coordinate with backports team to do a test upload to -backports to check if it builds correctly everywhere * also do an upload of a package that needs signing * this will probably need NEW processing by backports admins * Have DSA upgrade a non-critical machine * Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run) * Have DSA upgrade a buildd for each architecture * Do a checklist for each architecture/buildd machine * Have DSA contact DebianList:debian-services-admin to ask service maintainers to prepare their services for the new release ([[https://lists.debian.org/msgid-search/1477278955.2136.1.camel@debian.org|example mail]]) * and include [[how-can-i-help]] output for the package list from each debian.org machine * Coordinate plan for English review + translators of the release-notes, so everyone has time to do their work. * Some chapters can freeze before others (Notably, the "Issues" will want to stay open as long as possible) * Mail: debian-l10n-english@, debian-i18n@, debian-doc@. debian-release@ * Ensure that www/freeze-and-release-dates.yaml is up-to-date |
* (./) Decide on a code name for ''bullseye+2'': [[https://lists.debian.org/msgid-search/45fe5df0-c72d-cd61-ffb3-4b43a813262f@debian.org|trixie]] * (./) Get that included in BTS tags: * (./) @gTags in /srv/bugs.debian.org/etc/config on bugs-master.debian.org * (./) bts_release_tags and bts_release_ignore_tags [[https://salsa.debian.org/webmaster-team/webwml/blob/master/english/Bugs/pkgreport-opts.inc|in webwml]] * (./) Edit wiki pages to add trixie: DebianReleases DebianTrixie DebianBookworm [[Glossary]] * (./) Add deb.li pages for bullseye+2: [[https://deb.li/trixie|trixie]] [[https://deb.li/gettrixie|gettrixie]] * (./) Edit/create wiki pages for bullseye: ReleaseParty ReleasePartyBullseye DebianBullseye NewInBullseye * (./) Update deb.li pages to use bullseye: [[https://deb.li/relparty|relparty]] * (./) Theme (artwork) design should be finalised and decided * (./) Prepare the website changes * (./) Ensure that the following pages exist on debian.org/releases/bullseye * (./) index * (./) credits * (./) errata * (./) installmanual (requires installmanual is being built for bullseye as well) * (./) releasenotes (requires releasenotes is being built for bullseye as well) * (./) reportingbugs * (./) There should also be a page for debian.org/releases/bookworm as there are some links to it. * (./) The pages should say they are beta versions/not released etc. at this point * (./) Assert the architecture list is up to date (release.data), new ports should be available on https://debian.org/ports (ports/index.wml) * (./) Ensure that updates to the installation-guide appear on the website (d-i) [To avoid a repeat of <<mid(20170605233204.GB24136@mraw.org)>>] * (./) Ensure that updates to the release-notes appear on the website * (./) Decide on Release Architectures * [ ] Ensure image builds work for all release architectures * (./) Generate and add release keys to debian-archive-keyring (see [[DebianBug:977910|#977910]] + [[DebianBug:977910|#977911]]) * (./) SRMs generate one (technically, RMs can generate it too, but SRMs will need it post release) * (./) "reportbug ftp.debian.org" to get it added to https://ftp-master.debian.org/keys.html * (./) FTP-masters generate several (see <<mid(878tlll6zo.fsf@deep-thought.43-1.org)>>) * (./) Have FTP masters create security + backports archive for upcoming release * [ ] Re Announcements: Remember to clarify that -backports is a read-only to the sake of assisting with upgrades. * [ ] Remember to add the ACL to the new stable-backports and oldstable-backports-sloppy suites * (./) Coordinate with security team to do a test upload to -security to check if it builds correctly everywhere * (./) also do an upload of a package that needs signing * [ ] Coordinate with backports team to do a test upload to -backports to check if it builds correctly everywhere [2021-04-01 elbrus: mail sent] * [ ] also do an upload of a package that needs signing * [ ] this will probably need NEW processing by backports admins * [ ] Have DSA upgrade a non-critical machine [2021-02-25 <<mid(60859e49-19c2-edae-2e59-c1536446f8e3@debian.org)>>] * [ ] Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run) * [ ] Have DSA upgrade a buildd for each architecture (x86-ubc-01 <<mid(YGT045niuQQbQ8fj@aurel32.net)>>) * [ ] Do a checklist for each architecture/buildd machine * (./) Have DSA contact DebianList:debian-services-admin to ask service maintainers to prepare their services for the new release ([[https://lists.debian.org/debian-services-admin/2021/02/msg00000.html|sent]]) * [ ] and include [[how-can-i-help]] output for the package list from each debian.org machine * (./) Coordinate plan for English review + translators of the release-notes, so everyone has time to do their work. * (./) Some chapters can freeze before others (Notably, the "Issues" will want to stay open as long as possible) * (./) Mail: debian-l10n-english@, debian-i18n@, debian-doc@. debian-release@ * (./) Ensure that www/freeze-and-release-dates.yaml is up-to-date |
Line 76: | Line 77: |
* binNMU everything that has a Built-Using header and is using old versions to remove old source packages from the release. * d-i should have (beta or even better rc) releases * Do at least one DVD making dry run with the right installer, to ensure that everything fits properly. * Install Guide should be up-to-date * ReleaseNotes need to be updated: * Check with [[Teams/DebianKernel|Linux kernel team]] for specials with the Kernel * Check with d-i team for specials with this update (check esp. if old versions of d-i should be purged if new versions enter $suite's d-i area) * Check with [[Teams/Security|Security Team]] for lower supported packages * Install & upgrade tests should reveal no undocumented (release notes, install guide) surprises * Coordinate a release date at least 3 weeks before - involved teams/roles: * Required * FTP-masters * SRMs (need to sign the Release file for "stable" that becomes "oldstable") * Image team / Install media team * Press (media coverage + sending the press announcement) * Optional or/and Vetoers: * d-i (optional for the day itself, but can veto the day - if d-i doesn't work, we cannot release) * DSA (optional, but good to have in case of issues) * Announce the release date on d-d-a, preferably coordinated with press@ / #d-publicity so they can do micronews * Ensure that the planned release date is added to debian.org/releases * Ensure that release.debian.org mentions the release date under "Key release dates" * Add release dates and relevant deadlines to the release calendar. * Ensure that www/freeze-and-release-dates.yaml is up-to-date * Website: * Have a patch ready for template/debian/release_info.wml to update * Notify the [[Teams/Security|Security Team]] of an upcoming Release * Notify the [[Teams/DebianCd|Debian CD]] team of an upcoming Release * Notify the DebianLive Team of an upcoming Release * Notify the Mirror team of an upcoming Release * Notify the [[Teams/Publicity|publicity]] team of an upcoming Release * Prepare [[Teams/Publicity/Announcements|press release]] * coordinate with d-i team for text for d-i changes * Prepare the wiki changes |
* (./) binNMU everything that has a Built-Using header and is using old versions to remove old source packages from the release. * (./) d-i should have (beta or even better rc) releases * [ ] Do at least one DVD making dry run with the right installer, to ensure that everything fits properly. * (./) Install Guide should be up-to-date <<mid(20210415193834.98dd19e9852dc3db344e9312@mailbox.org)>> * (./) ReleaseNotes need to be updated: * [ ] Check with [[Teams/DebianKernel|Linux kernel team]] for specials with the Kernel <<mid(04e177b7-be29-f6ca-3556-ca1ef518e1db@debian.org)>> * (./) Check with d-i team for specials with this update (check esp. if old versions of d-i should be purged if new versions enter bullseye's d-i area) <<mid(c5ea0d37-4afd-2c9d-46fe-2b14f43bd2c7@debian.org)>> * (./) Check with [[Teams/Security|Security Team]] for lower supported packages <<mid(25d517ca-15a2-d03a-d4f2-b82c4f993eaa@debian.org)>> * (./) Install & upgrade tests should reveal no undocumented (release notes, install guide) surprises * (./) Coordinate a release date at least 3 weeks before - involved teams/roles: <<mid(dea041f3-aa25-e0e5-48a4-12b288e4ab60@debian.org)>> * (./) Required * (./) FTP-masters * (./) SRMs (need to sign the Release file for "stable" that becomes "oldstable") * (./) Image team / Install media team * (./) Press (media coverage + sending the press announcement) * (./) Optional or/and Vetoers: * (./) d-i (optional for the day itself, but can veto the day - if d-i doesn't work, we cannot release) * [ ] DSA (optional, but good to have in case of issues) * (./) Announce the release date on d-d-a, preferably coordinated with press@ / #d-publicity so they can do micronews * [ ] Ensure that the planned release date is added to debian.org/releases * (./) Ensure that release.debian.org mentions the release date under "Key release dates" * (./) Add release dates and relevant deadlines to the release calendar. * (./) Ensure that www/freeze-and-release-dates.yaml is up-to-date * [ ] Website: * [ ] Have a patch ready for template/debian/release_info.wml to update * [ ] Notify the [[Teams/Security|Security Team]] of an upcoming Release * [ ] Notify the [[Teams/DebianCd|Debian CD]] team of an upcoming Release * [ ] Notify the DebianLive Team of an upcoming Release * [ ] Notify the Mirror team of an upcoming Release * [ ] Notify the [[Teams/Publicity|publicity]] team of an upcoming Release * [ ] Prepare [[Teams/Publicity/Announcements|press release]] * [ ] coordinate with d-i team for text for d-i changes * [ ] Prepare the wiki changes |
Line 112: | Line 113: |
* Mention things that are happening on IRC so the [[Teams/Publicity|publicity]] team can [[Teams/Publicity/Release|relay]] to social media * Check with the FTP-Masters * d-i needs to be moved * new win32-loader? * cleanup of $codename-proposed-updates and $codename-security * stable-updates needs its suite name hack updated to oldstable-updates * debtags need to be copied from unstable * Check /srv/ftp-master.debian.org/ftp/dists/$codename/ChangeLog * Check if /srv/ftp.debian.org/ftp/README was updated. * Sign the release file * Check that everything that should be released really was released * Notify [[mailto:debian-security@lists.debian.org|debian-security]] as people tend to cry occasionally * Notify the Publicity Team, that Release is done (tell them when the Release will be pushed out) * Notify the [[Teams/DebianCd|Debian CD]] Team that the Release is done * Notify the DebianLive Team that the Release is done * Update the website * Publish the ReleaseNotes * Notify the Debian WWW team that the Release is done and is time to update the website * Ask www team to update english/releases/ * Ask service owner to update packages.debian.org search interface (default to new stable release) * Ask publicity team to publish Release Announcement in website news area * Ask www team to force website update * Check afer update the website to make sure that it refers to new stable in [[http://www.debian.org/releases/|release pages]] * Update Wiki: * Update these wiki pages (coordinated with ReleaseNotes's editor): FrontPage DebianReleases [[Status/Stable]] StableUpdates StableProposedUpdates [[Backports]] [[Welcome/Users]] [[Glossary]] [[Debian<RELEASENAME>]] [[Debian<RELEASENAME-1>]] [[Debian<RELEASENAME+1>]] ReleaseParty [[ReleaseParty<RELEASENAME>]] [[ReleaseParty<RELEASENAME+1>]] [[DebianArt/Themes]] [[DebianDesktop/Artwork]] [[DebianDesktop/Artwork/<RELEASENAME+1>]] [[ArchiveQualification/<RELEASENAME+1>]] [[Teams/DebianCD/ReleaseTesting]] [[Teams/Dpkg/FAQ]] SourcesList * Ping the wiki team to run /srv/wiki.debian.org/bin/get-debian-suite-info * Watch mailing-lists for abnormalities * Backup/flush hint files. * Update release.debian.org/{oldoldstable,oldstable,stable,testing} symlinks; create the new suite for testing as a copy of stable and edit |
* [ ] Mention things that are happening on IRC so the [[Teams/Publicity|publicity]] team can [[Teams/Publicity/Release|relay]] to social media * [ ] Check with the FTP-Masters * [ ] d-i needs to be copied to the new testing * [ ] new win32-loader? * [ ] cleanup of bullseye-proposed-updates and bullseye-security * [ ] stable-updates needs its suite name hack updated to oldstable-updates * [ ] debtags need to be copied from unstable * [ ] Check /srv/ftp-master.debian.org/ftp/dists/bullseye/ChangeLog * [ ] Check if /srv/ftp.debian.org/ftp/README was updated. * [ ] Sign the release file * [ ] Check that everything that should be released really was released * [ ] Notify [[mailto:debian-security@lists.debian.org|debian-security]] as people tend to cry occasionally * [ ] Notify the Publicity Team, that Release is done (tell them when the Release will be pushed out) * [ ] Notify the [[Teams/DebianCd|Debian CD]] Team that the Release is done * [ ] Notify the DebianLive Team that the Release is done * [ ] Update the website * [ ] Publish the ReleaseNotes * [ ] Notify the Debian WWW team that the Release is done and is time to update the website * [ ] Ask www team to update english/releases/ * [ ] Ask service owner to update packages.debian.org search interface (default to new stable release) * [ ] Ask publicity team to publish Release Announcement in website news area * [ ] Ask www team to force website update * [ ] Check afer update the website to make sure that it refers to new stable in [[http://www.debian.org/releases/|release pages]] * [ ] Update Wiki: * [ ] Update these wiki pages (coordinated with ReleaseNotes's editor): FrontPage DebianReleases [[Status/Stable]] StableUpdates StableProposedUpdates [[Backports]] [[Welcome/Users]] [[Glossary]] [[DebianBullseye]] [[DebianBuster]] [[DebianBookworm]] ReleaseParty [[ReleasePartyBullseye]] [[DebianArt/Themes]] [[DebianDesktop/Artwork]] [[DebianDesktop/Artwork/Bookworm]] [[ArchiveQualification/Bookworm]] [[Teams/DebianCD/ReleaseTesting]] [[Teams/Dpkg/FAQ]] SourcesList * [ ] Ping the wiki team to run /srv/wiki.debian.org/bin/get-debian-suite-info * [ ] Watch mailing-lists for abnormalities * [ ] Backup/flush hint files. * [ ] Update release.debian.org/{oldoldstable,oldstable,stable,testing} symlinks; create the new suite for testing as a copy of stable and edit |
Line 144: | Line 145: |
* Notify Distrowatch; send a mail to distro@distrowatch.com * Notify [[https://lwn.net/op/FAQ.lwn#contact|LWN]], [[http://slashdot.org/submission|slashdot]], [[https://news.ycombinator.com/|Hacker News]], [[http://www.reddit.com/r/debian|Reddit]], [[https://freshcode.club/|fresh(code)]] * [[Teams/Publicity/micronews|Propose]] a micronews item on the [[irc://irc.debian.org/debian-publicity|#debian-publicity]] [[IRC]] channel * Blog about release team experiences * Bits from the release team mail * Update the [[Teams/Publicity/Timeline|Debian timeline]] * Update the [[https://www.debian.org/doc/misc-manuals#history|Project History]] document and upload to stable-p-u * Notify [[Derivatives/CensusQA#release|derivatives]] about the release * Update all the places that [[SuitesAndReposExtension#Existing_hardcoding|hardcode]] suite names or codenames * Notify owner@bugs.debian.org that the codename to suite mapping needs to be updated on the RC bugs pages: https://bugs.debian.org/release-critical/debian/ * Notify the web team that they should ping [[https://www.debian.org/users/|Debian users]] after a few months to check if they are still using Debian and to update their testimonials * Add a tag for the new testing to all bugs tagged 'sid' |
* [ ] Notify Distrowatch; send a mail to distro@distrowatch.com * [ ] Notify [[https://lwn.net/op/FAQ.lwn#contact|LWN]], [[http://slashdot.org/submission|slashdot]], [[https://news.ycombinator.com/|Hacker News]], [[http://www.reddit.com/r/debian|Reddit]], [[https://freshcode.club/|fresh(code)]] * [ ] [[Teams/Publicity/micronews|Propose]] a micronews item on the [[irc://irc.debian.org/debian-publicity|#debian-publicity]] [[IRC]] channel * [ ] Blog about release team experiences * [ ] Bits from the release team mail * [ ] Update the [[Teams/Publicity/Timeline|Debian timeline]] * [ ] Update the [[https://www.debian.org/doc/misc-manuals#history|Project History]] document and upload to stable-p-u * [ ] Notify [[Derivatives/CensusQA#release|derivatives]] about the release * [ ] Update all the places that [[SuitesAndReposExtension#Existing_hardcoding|hardcode]] suite names or codenames * [ ] Notify owner@bugs.debian.org that the codename to suite mapping needs to be updated on the RC bugs pages: https://bugs.debian.org/release-critical/debian/ * [ ] Notify the web team that they should ping [[https://www.debian.org/users/|Debian users]] after a few months to check if they are still using Debian and to update their testimonials * [ ] Add a tag for the new testing to all bugs tagged 'sid' |
Line 158: | Line 159: |
* Ensure that the BTS knows that testing has changed (to stop RC bugs regressions from migrating to testing) * Ensure other data sources give information about the new testing * Ensure dinstall run smoothly |
* [ ] Ensure that the BTS knows that testing has changed (to stop RC bugs regressions from migrating to testing) * [ ] Ensure other data sources give information about the new testing * [ ] Ensure dinstall run smoothly |
This is a RM's TODO list, which might not be authoritative or complete.
The following things need to be done for the bullseye release:
Tagging RC Bugs
At some point, we will have to tag the remaining RC bugs to filter what should be removed/deferred/fixed. It's possible to define our own sorting criteria by sending the following request to request@bugs.debian.org:
user release.debian.org@packages.debian.org usercategory bullseye-sort * bullseye [tag=] + Blockers for bullseye [bullseye-is-blocker] + Planned for removal [bullseye-will-remove] + Ignored for bullseye [bullseye-can-defer]
Then, usertagged bugs will be listed on:
Useful references about this feature are:
Before freeze
Decide on a code name for bullseye+2: trixie
Get that included in BTS tags:
@gTags in /srv/bugs.debian.org/etc/config on bugs-master.debian.org
bts_release_tags and bts_release_ignore_tags in webwml
Edit wiki pages to add trixie: DebianReleases DebianTrixie DebianBookworm Glossary
Edit/create wiki pages for bullseye: ReleaseParty ReleasePartyBullseye DebianBullseye NewInBullseye
Update deb.li pages to use bullseye: relparty
Theme (artwork) design should be finalised and decided
Prepare the website changes
Ensure that the following pages exist on debian.org/releases/bullseye
index
credits
errata
installmanual (requires installmanual is being built for bullseye as well)
releasenotes (requires releasenotes is being built for bullseye as well)
reportingbugs
There should also be a page for debian.org/releases/bookworm as there are some links to it.
The pages should say they are beta versions/not released etc. at this point
Assert the architecture list is up to date (release.data), new ports should be available on https://debian.org/ports (ports/index.wml)
Ensure that updates to the installation-guide appear on the website (d-i) [To avoid a repeat of <20170605233204.GB24136@mraw.org>]
Ensure that updates to the release-notes appear on the website
Decide on Release Architectures
- [ ] Ensure image builds work for all release architectures
Generate and add release keys to debian-archive-keyring (see #977910 + #977911)
SRMs generate one (technically, RMs can generate it too, but SRMs will need it post release)
"reportbug ftp.debian.org" to get it added to https://ftp-master.debian.org/keys.html
FTP-masters generate several (see <878tlll6zo.fsf@deep-thought.43-1.org>)
Have FTP masters create security + backports archive for upcoming release
- [ ] Re Announcements: Remember to clarify that -backports is a read-only to the sake of assisting with upgrades.
- [ ] Remember to add the ACL to the new stable-backports and oldstable-backports-sloppy suites
Coordinate with security team to do a test upload to -security to check if it builds correctly everywhere
also do an upload of a package that needs signing
- [ ] Coordinate with backports team to do a test upload to -backports to check if it builds correctly everywhere [2021-04-01 elbrus: mail sent]
- [ ] also do an upload of a package that needs signing
- [ ] this will probably need NEW processing by backports admins
[ ] Have DSA upgrade a non-critical machine [2021-02-25 <60859e49-19c2-edae-2e59-c1536446f8e3@debian.org>]
- [ ] Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run)
[ ] Have DSA upgrade a buildd for each architecture (x86-ubc-01 <YGT045niuQQbQ8fj@aurel32.net>)
- [ ] Do a checklist for each architecture/buildd machine
Have DSA contact debian-services-admin to ask service maintainers to prepare their services for the new release (sent)
[ ] and include how-can-i-help output for the package list from each debian.org machine
Coordinate plan for English review + translators of the release-notes, so everyone has time to do their work.
Some chapters can freeze before others (Notably, the "Issues" will want to stay open as long as possible)
Mail: debian-l10n-english@, debian-i18n@, debian-doc@. debian-release@
Ensure that www/freeze-and-release-dates.yaml is up-to-date
Before a Release
binNMU everything that has a Built-Using header and is using old versions to remove old source packages from the release.
d-i should have (beta or even better rc) releases
- [ ] Do at least one DVD making dry run with the right installer, to ensure that everything fits properly.
Install Guide should be up-to-date <20210415193834.98dd19e9852dc3db344e9312@mailbox.org>
ReleaseNotes need to be updated:
[ ] Check with Linux kernel team for specials with the Kernel <04e177b7-be29-f6ca-3556-ca1ef518e1db@debian.org>
Check with d-i team for specials with this update (check esp. if old versions of d-i should be purged if new versions enter bullseye's d-i area) <c5ea0d37-4afd-2c9d-46fe-2b14f43bd2c7@debian.org>
Check with Security Team for lower supported packages <25d517ca-15a2-d03a-d4f2-b82c4f993eaa@debian.org>
Install & upgrade tests should reveal no undocumented (release notes, install guide) surprises
Coordinate a release date at least 3 weeks before - involved teams/roles: <dea041f3-aa25-e0e5-48a4-12b288e4ab60@debian.org>
Required
FTP-masters
SRMs (need to sign the Release file for "stable" that becomes "oldstable")
Image team / Install media team
Press (media coverage + sending the press announcement)
Optional or/and Vetoers:
d-i (optional for the day itself, but can veto the day - if d-i doesn't work, we cannot release)
- [ ] DSA (optional, but good to have in case of issues)
Announce the release date on d-d-a, preferably coordinated with press@ / #d-publicity so they can do micronews
- [ ] Ensure that the planned release date is added to debian.org/releases
Ensure that release.debian.org mentions the release date under "Key release dates"
Add release dates and relevant deadlines to the release calendar.
Ensure that www/freeze-and-release-dates.yaml is up-to-date
- [ ] Website:
- [ ] Have a patch ready for template/debian/release_info.wml to update
[ ] Notify the Security Team of an upcoming Release
[ ] Notify the Debian CD team of an upcoming Release
[ ] Notify the DebianLive Team of an upcoming Release
- [ ] Notify the Mirror team of an upcoming Release
[ ] Notify the publicity team of an upcoming Release
[ ] Prepare press release
- [ ] coordinate with d-i team for text for d-i changes
- [ ] Prepare the wiki changes
While Releasing
[ ] Mention things that are happening on IRC so the publicity team can relay to social media
- [ ] Check with the FTP-Masters
- [ ] d-i needs to be copied to the new testing
- [ ] new win32-loader?
- [ ] cleanup of bullseye-proposed-updates and bullseye-security
- [ ] stable-updates needs its suite name hack updated to oldstable-updates
- [ ] debtags need to be copied from unstable
- [ ] Check /srv/ftp-master.debian.org/ftp/dists/bullseye/ChangeLog
- [ ] Check if /srv/ftp.debian.org/ftp/README was updated.
- [ ] Sign the release file
- [ ] Check that everything that should be released really was released
[ ] Notify debian-security as people tend to cry occasionally
- [ ] Notify the Publicity Team, that Release is done (tell them when the Release will be pushed out)
[ ] Notify the Debian CD Team that the Release is done
[ ] Notify the DebianLive Team that the Release is done
- [ ] Update the website
[ ] Publish the ReleaseNotes
- [ ] Notify the Debian WWW team that the Release is done and is time to update the website
- [ ] Ask www team to update english/releases/
- [ ] Ask service owner to update packages.debian.org search interface (default to new stable release)
- [ ] Ask publicity team to publish Release Announcement in website news area
- [ ] Ask www team to force website update
[ ] Check afer update the website to make sure that it refers to new stable in release pages
- [ ] Update Wiki:
[ ] Update these wiki pages (coordinated with ReleaseNotes's editor): FrontPage DebianReleases Status/Stable StableUpdates StableProposedUpdates Backports Welcome/Users Glossary DebianBullseye DebianBuster DebianBookworm ReleaseParty ReleasePartyBullseye DebianArt/Themes DebianDesktop/Artwork DebianDesktop/Artwork/Bookworm ?ArchiveQualification/Bookworm Teams/DebianCD/ReleaseTesting Teams/Dpkg/FAQ SourcesList
- [ ] Ping the wiki team to run /srv/wiki.debian.org/bin/get-debian-suite-info
- [ ] Watch mailing-lists for abnormalities
- [ ] Backup/flush hint files.
- [ ] Update release.debian.org/{oldoldstable,oldstable,stable,testing} symlinks; create the new suite for testing as a copy of stable and edit
After the release
[ ] Notify Distrowatch; send a mail to distro@distrowatch.com
[ ] Notify LWN, slashdot, Hacker News, Reddit, fresh(code)
[ ] Propose a micronews item on the #debian-publicity IRC channel
- [ ] Blog about release team experiences
- [ ] Bits from the release team mail
[ ] Update the Debian timeline
[ ] Update the Project History document and upload to stable-p-u
[ ] Notify derivatives about the release
[ ] Update all the places that hardcode suite names or codenames
[ ] Notify owner@bugs.debian.org that the codename to suite mapping needs to be updated on the RC bugs pages: https://bugs.debian.org/release-critical/debian/
[ ] Notify the web team that they should ping Debian users after a few months to check if they are still using Debian and to update their testimonials
- [ ] Add a tag for the new testing to all bugs tagged 'sid'
Before enabling Britney and removing freeze hints
- [ ] Ensure that the BTS knows that testing has changed (to stop RC bugs regressions from migrating to testing)
- [ ] Ensure other data sources give information about the new testing
- [ ] Ensure dinstall run smoothly
- ...