Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• BookwormCheckList

This is a RM's TODO list, which might not be authoritative or complete.

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 bookworm-sort
  * bookworm [tag=]
    + Blockers for bookworm [bookworm-is-blocker]
    + Planned for removal [bookworm-will-remove]
    + Ignored for bookworm [bookworm-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=bookworm-can-defer;tag=bookworm-will-remove;tag=bookworm-is-blocker;ordering=bookworm-sort

Useful references about this feature are:

• #424427: [bts] should support usercategory

• Devscripts/bugs

Another very useful view on the RC bugs is via this udd view.

Before freeze

• Decide on a code name for bookworm+2: forky

  • Get that included in BTS tags:

    • @gTags in /srv/bugs.debian.org/etc/config on bugs-master.debian.org (1029978)

    • bts_release_tags and bts_release_ignore_tags in webwml

  • Edit wiki pages to add forky: DebianReleases DebianForky DebianTrixie Glossary

  • Add deb.li pages for bookworm+2: forky getforky

• Edit/create wiki pages for bookworm: ReleaseParty ReleasePartyBookworm DebianBookworm NewInBookworm

• Update deb.li pages to use bookworm: relparty

• Theme (artwork) design should be finalised and decided announcement

• Prepare the website changes

  • Ensure that the following pages exist on https://debian.org/releases/bookworm

    • index

    • credits

    • errata

    • installmanual (requires installmanual is being built for bookworm as well)

    • releasenotes (requires releasenotes is being built for bookworm as well)

    • reportingbugs

  • There should also be a page for debian.org/releases/trixie 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 1029215 + 1029214)

  • 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 (see 1034259)

  • FTP-masters generate several (announcement)

• 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 bookworm-backports and bullseye-backports-sloppy suites

• Coordinate with security team to do a test upload to -security to check if it builds correctly everywhere (summary)

  • 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 (email sent 2023-04-11)

  • [ ] 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 (request)

  • [ ] Suggestions include:

• [ ] Have DSA upgrade a buildd for each architecture (request)

  • [ ] Do a checklist for each architecture/buildd machine

• Have DSA contact debian-services-admin to ask service maintainers to prepare their services for the bookworm release (e-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@ <312fac26-4977-9e7e-1963-ad7ee1e993da@debian.org>

• Ensure that www/testing/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

• Make sure that reportbug contains the right stable to suite name tables. See: https://salsa.debian.org/reportbug-team/reportbug/-/commit/0bf36604535e0c4bf8c39a27d0d3901095ea57ae for details. (1034260)

• [ ] 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 bookworm'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: (e-mail)

  • 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 (e-mail)

  • 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 (f961a81)

• 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 (done by Publicity Team)

  • [ ] 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 trixie

  • new win32-loader?

  • [ ] cleanup of bookworm-proposed-updates and bookworm-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/bookworm/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 bookworm)

  • 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 bookworm in release pages

• [ ] Update Wiki:

  • [ ] Update these wiki pages (coordinated with ReleaseNotes's editor): FrontPage DebianReleases ReleaseRecertification StableUpdates StableProposedUpdates Backports Welcome/Users Glossary DebianBookworm DebianBullseye DebianTrixie ReleaseParty ReleasePartyBookworm DebianArt/Themes DebianDesktop/Artwork DebianDesktop/Artwork/Trixie 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 trixie for testing as a copy of bookworm and edit

After the release

• Notify Distrowatch; send a mail to distro@distrowatch.com

• Notify LWN

• [ ] Notify 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

• 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 trixie to all bugs tagged 'sid'

• Remove -ignore tags from bugs in bookworm that are candidates for fixing in point releases

• Check with udd maintainers that the hardcoded values are updated (see SuitesAndReposExtension#udd)

• [ ] Check with buildd team that buildds know about trixie. (see SuitesAndReposExtension#wanna-build)

• [ ] Check with other service/package maintainers that all the other hardcoded suite names or codenames are updated

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 trixie

• Ensure dinstall run smoothly

• Ensure trille is cron-ed if it was disabled for the week before the release

• [ ] ...