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 trixie-sort
* trixie [tag=]
+ Blockers for trixie [trixie-is-blocker]
+ Planned for removal [trixie-will-remove]
+ Ignored for trixie [trixie-can-defer]Then, usertagged bugs will be listed on:
Useful references about this feature are:
Another very useful view on the RC bugs is via this udd view.
Before freeze
Decide on a code name for trixie+2: duke - [ ] Get that included in BTS tags:
- [ ] @gTags in /srv/bugs.debian.org/etc/config on bugs-master.debian.org [mail sent to owner@]
[ ] bts_release_tags and bts_release_ignore_tags in webwml
- Edit wiki pages to add duke: DebianReleases DebianDuke DebianForky Glossary
- [ ] Get that included in BTS tags:
- Edit/create wiki pages for trixie: ReleaseParty ReleasePartyTrixie DebianTrixie NewInTrixie
- Update deb.li pages to use trixie: relparty
- Theme (artwork) design should be finalized and decided
- Prepare the website changes
- Ensure that the following pages exist on https://debian.org/releases/trixie
- index
- credits
- errata
- installmanual (requires installmanual is being built for trixie as well)
- releasenotes (requires releasenotes is being built for trixie as well)
[ ] reportingbugs (not needed, we now use https://www.debian.org/releases/reportingbugs for all releases)
- There should also be a page for https://debian.org/releases/forky 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 (1107348 )
- 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 trixie-backports and bookworm-backports-sloppy suites
- Coordinate with security team to do a test upload to -security to check if it builds correctly everywhere <fc3bce91-2cbe-44fc-a170-006812a27ef4@debian.org>
- 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 <8d3458e6-9821-40d7-852c-9477ae357ffa@debian.org>
- [ ] 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 trixie 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/testing/freeze-and-release-dates.yaml is up-to-date
- [ ] For trixie only: check that all packages have been rebuilt for the time_t transition on arm{el,hf}
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. 1106102
- 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 trixie'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
[ ] 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
- [ ] 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 forky
- [ ] new win32-loader?
- [ ] cleanup of trixie-proposed-updates and trixie-security
- [ ] oldstable-updates needs its suite_name updated to oldoldstable-updates in dak (legacy)
- [ ] debtags need to be copied from unstable
- Check /srv/ftp-master.debian.org/ftp/dists/trixie/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 trixie)
- 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 trixie in release pages
- [ ] Update Wiki:
[ ] Update these wiki pages (coordinated with ReleaseNotes's editor): FrontPage DebianReleases ReleaseRecertification StableUpdates StableProposedUpdates Backports Welcome/Users Glossary DebianTrixie DebianBookworm DebianForky ReleaseParty ReleasePartyTrixie DebianArt/Themes DebianDesktop/Artwork ?DebianDesktop/Artwork/Forky 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 forky for testing as a copy of trixie and edit
[ ] Update these wiki pages that link to release.d.o codenames: ReleaseRecertification
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
[ ] 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 forky to all bugs tagged 'sid'
- [ ] Remove -ignore tags from bugs in trixie 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 forky. (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 forky
- piuparts
- reproducible
- Ensure dinstall run smoothly
- Ensure trille is cronned if it was disabled for the week before the release
- Fix symlinks in respighi:/srv/release.debian.org/www/britney