Differences between revisions 1 and 4 (spanning 3 versions)
Revision 1 as of 2021-01-21 20:53:40
Size: 10864
Editor: PaulGevers
Comment: Copy / paste from the template
Revision 4 as of 2021-01-22 00:07:42
Size: 11057
Editor: PaulWise
Comment: revert some codename replacements that were not needed
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 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''
   * [ ] 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
Line 116: Line 115:
   * cleanup of $codename-proposed-updates and $codename-security    * cleanup of $bullseye-proposed-updates and $bullseye-security
Line 119: Line 118:
 * Check /srv/ftp-master.debian.org/ftp/dists/$codename/ChangeLog  * Check /srv/ftp-master.debian.org/ftp/dists/$bullseye/ChangeLog

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

    • [ ] 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 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 <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)
  • [ ] 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 debian-services-admin to ask service maintainers to prepare their services for the new release (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

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
  • ReleaseNotes need to be updated:

    • Check with 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 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 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 moved
    • 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 afer 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
  • ...