• Diff for "Teams/ReleaseTeam/ReleaseCheckList"

This is template of the RM's TODO list, which might not be authoritative or complete. To create a new release TODO list, add it to the list below and replace the @codename-1@ @codename@ @codename+1@ @codename+2@ etc placeholders, ensuring that you preserve the case of the placeholders in the values; replace "@Codename@" with "Bullseye" not bullseye".

• Bullseye TODO list

• Buster TODO list

• 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 request@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: @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 @codename+2@: DebianReleases Debian@Codename+2@ Debian@Codename+1@ Glossary

  • [ ] Add deb.li pages for @codename@+2: @codename+2@ get@codename+2@

• [ ] Edit/create wiki pages for @codename@: ReleaseParty ReleaseParty@Codename@ Debian@Codename@ ?NewIn@Codename@

• [ ] Update deb.li pages to use @codename@: relparty

• [ ] Theme (artwork) design should be finalised and decided
• [ ] Prepare the website changes
  • [ ] Ensure that the following pages exist on debian.org/releases/@codename@
    • [ ] index
    • [ ] credits
    • [ ] errata
    • [ ] installmanual (requires installmanual is being built for @codename@ as well)
    • [ ] releasenotes (requires releasenotes is being built for @codename@ as well)
    • [ ] reportingbugs
  • [ ] There should also be a page for debian.org/releases/@codename+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)

    • [ ] "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 read-only for the sake of assisting with upgrades.
  • [ ] Remember to add the ACL to the @codename@-backports and @codename-1@-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:
• [ ] 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 @codename@ 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 @codename@'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

• [ ] 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 @codename+1@
  • [ ] 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 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 @codename@)
  • [ ] Ask publicity team to publish Release Announcement in website news area
  • [ ] Ask www team to force website update

  • [ ] Check after the website update to make sure that it refers to @codename@ in release pages

• [ ] Update Wiki:

  • [ ] Update these wiki pages (coordinated with ReleaseNotes's editor): FrontPage DebianReleases Status/Stable StableUpdates StableProposedUpdates Backports Welcome/Users Glossary ?Debian@Codename@ ?Debian@Codename-1@ ?Debian@Codename+1@ ReleaseParty ?ReleaseParty@Codename@ DebianArt/Themes DebianDesktop/Artwork ?DebianDesktop/Artwork/@Codename+1@ ?ArchiveQualification/@Codename+1@ Teams/DebianCD/ReleaseTesting Teams/Dpkg/FAQ SourcesList

  • [ ] Ping the wiki team to run /srv/wiki.debian.org/bin/get-debian-suite-info early (cron runs @daily)
• [ ] Watch mailing-lists for abnormalities
• [ ] Backup/flush hint files.
• [ ] Update release.debian.org/{oldoldstable,oldstable,stable,testing} symlinks; create @codename+1@ for testing as a copy of @codename@ 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 @codename+1@ to all bugs tagged 'sid'
• [ ] Remove -ignore tags from bugs in @codename@ that are candidates for fixing in point releases

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 @codename+1@
• [ ] Ensure dinstall run smoothly
• [ ] Ensure trille is croned if it was disabled for the week before the release
• [ ] ...