Differences between revisions 43 and 46 (spanning 3 versions)
⇤ ← Revision 43 as of 2021-08-10 13:03:11 →
Size: 12059
Editor: PaulGevers
Comment: Teams are noitified (or involved in the date picking process)
← Revision 46 as of 2021-08-14 09:17:54 → ⇥
Size: 12359
Editor: ?JonathanWiltshire
Comment:
Deletions are marked like this. Additions are marked like this.
Line 107: Line 107:
 * (./) Decron trille for the week before the release to avoid daily emails with the same stale contents
Line 113: Line 114:
 * [ ] Mention things that are happening on IRC so the [[Teams/Publicity|publicity]] team can [[Teams/Publicity/Release|relay]] to social media  * (./) Mention things that are happening on IRC so the [[Teams/Publicity|publicity]] team can [[Teams/Publicity/Release|relay]] to social media
Line 115: Line 116:
   * [ ] d-i needs to be copied to the new testing
   * [ ] new win32-loader?		    * (./) d-i needs to be copied to the new testing
   * (./) new win32-loader?
Line 120: Line 121:
 * [ ] 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 /srv/ftp-master.debian.org/ftp/dists/bullseye/ChangeLog
 * (./) Check if /srv/ftp.debian.org/ftp/README was updated.
 * (./) Sign the release file
Line 157: Line 158:
 * [ ] Remove -ignore tags from bugs in the new stable that are candidates for fixing in point releases
Line 162: Line 164:
 * [ ] Ensure trille is croned if it was disabled for the week before the release

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

  • (./) Edit/create wiki pages for bullseye: ReleaseParty ReleasePartyBullseye DebianBullseye NewInBullseye

  • (./) Update deb.li pages to use bullseye: relparty

  • (./) Theme (artwork) design should be finalised and decided

  • (./) Prepare the website changes

    • (./) Ensure that the following pages exist on debian.org/releases/bullseye

      • (./) index

      • (./) credits

      • (./) errata

      • (./) installmanual (requires installmanual is being built for bullseye as well)

      • (./) releasenotes (requires releasenotes is being built for bullseye as well)

      • (./) reportingbugs

    • (./) There should also be a page for debian.org/releases/bookworm 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 #977910 + #977911)

  • (./) 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 [2021-04-01 elbrus: mail sent]
    • [ ] 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 [2021-02-25 <60859e49-19c2-edae-2e59-c1536446f8e3@debian.org>]

    • [ ] Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run)

  • [ ] Have DSA upgrade a buildd for each architecture (x86-ubc-01 <YGT045niuQQbQ8fj@aurel32.net>)

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

    • [ ] 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 <20210415193834.98dd19e9852dc3db344e9312@mailbox.org>

  • (./) ReleaseNotes need to be updated:

  • (./) Install & upgrade tests should reveal no undocumented (release notes, install guide) surprises

  • (./) Coordinate a release date at least 3 weeks before - involved teams/roles: <dea041f3-aa25-e0e5-48a4-12b288e4ab60@debian.org>

    • (./) 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 the new testing

    • (./) 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
  • [ ] Ensure trille is croned if it was disabled for the week before the release
  • ...