Differences between revisions 1 and 63 (spanning 62 versions)
Revision 1 as of 2021-01-21 20:53:40
Size: 10864
Editor: PaulGevers
Comment: Copy / paste from the template
Revision 63 as of 2021-08-16 07:00:46
Size: 12410
Editor: ?SebastianRamacher
Comment:
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
 * (./) Decron trille for the week before the release to avoid daily emails with the same stale contents
 * [ ]
Prepare [[Teams/Publicity/Announcements|press release]]
   * [ ] coordinate with d-i team for text for d-i changes
 * [ ] Prepare the wiki changes
Line 112: Line 114:
 * 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 after 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 ✓(part)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 146:
 * 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'
 * [ ] Remove -ignore tags from bugs in the new stable that are candidates for fixing in point releases
Line 158: Line 161:
 * 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
 * (./) Ensure trille is croned if it was disabled for the week before the release

<!> 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:

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

Useful references about this feature are:

Before freeze

  • (./) Decide on a code name for bullseye+2: trixie

  • (./) 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)

  • (./) 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:

  • (./) 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

  • (./) Decron trille for the week before the release to avoid daily emails with the same stale contents

  • [ ] 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
  • (./) 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 after update the website to make sure that it refers to new stable in release pages

  • [ ] Update Wiki:
  • [ ] 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

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
  • (./) Ensure trille is croned if it was disabled for the week before the release

  • ...