• Diff for "Teams/ReleaseTeam/ReleaseCheckList"

This is template of the RM's TODO list, which might not be authorative or complete.

• Stretch TODO list

The following things need to be done for a 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 control@bugs.debian.org:

user release.debian.org@packages.debian.org
usercategory codename-sort
  * Codename [tag=]
    + Blockers for Codename [codename-is-blocker]
    + Planned for removal [codename-will-remove]
    + Ignored for Codename [codename-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=codename-can-defer;tag=codename-will-remove;tag=codename-is-blocker;ordering=codename-sort

Useful references about this feature are:

• #424427: [bts] should support usercategory

• Devscripts/bugs

Before freeze

• 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 in webwml

  • Edit wiki pages to add the new release: ReleaseParty DebianReleases Debian<RELEASENAME> Debian<RELEASENAME-1> 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)
  • SRMs generate one (technically, RMs can generate it too, but SRMs will need it post release)

  • 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.
• Check with security team and backports team that it is possible to build uploads for -security and -backports
• 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@

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.
• 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 the Release

• 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 $codename-proposed-updates and $codename-security
  • stable-updates needs its suite name hack updated to oldstable-updates
• 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 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

• Update these wiki pages (coordinated with ReleaseNotes's editor): DebianReleases DebianReleases/PointReleases DebianStable DebianOldStable StableUpdates 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

• 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 tweet/dent on the #debian-publicity IRC channel

• Blog about release team experiences
• Bits from the release team mail

• Update the Debian timeline

• Notify derivatives about the release

• Update all the places that hardcode suite names or codenames