Differences between revisions 52 and 54 (spanning 2 versions)
Revision 52 as of 2019-07-07 01:49:27
Size: 11014
Editor: ?JonathanWiltshire
Revision 54 as of 2019-07-08 05:26:17
Size: 11015
Editor: PaulWise
Comment: wiki updates done
Deletions are marked like this. Additions are marked like this.
Line 132: Line 132:
 * [ ] Update Wiki:  * (./) Update Wiki:
Line 142: Line 142:
 * (./) Notify [[https://lwn.net/op/FAQ.lwn#contact|LWN]], [[https://news.ycombinator.com/|Hacker News]], [[http://www.reddit.com/r/debian|Reddit]] (they noticed)
 * [ ] Notify [[http://slashdot.org/submission|slashdot]], [[https://freshcode.club/|fresh(code)]]
 * (./) Notify [[https://lwn.net/op/FAQ.lwn#contact|LWN]], [[https://news.ycombinator.com/|Hacker News]], [[http://www.reddit.com/r/debian|Reddit]], [[http://slashdot.org/submission|slashdot]] (they noticed)
 * [ ] Notify [[https://freshcode.club/|fresh(code)]]

<!> This is a RM's TODO list for the Buster release, which might not be authorative or complete.

The following things need to be done for the Buster 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 buster-sort
  * Codename [tag=]
    + Blockers for Codename [buster-is-blocker]
    + Planned for removal [buster-will-remove]
    + Ignored for Codename [buster-can-defer]

Then, usertagged bugs will be listed on:


Useful references about this feature are:

Before freeze

  • (./) Decide on a code name for <codename>+2: bookworm

    • (./) Get that included in BTS tags (Filed as #917538):

      • (./) @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 DebianBuster DebianStretch NewInBuster 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/buster

      • (./) 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 [elbrus git pushed]
    • (./) 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>] [elbrus: on 2019-04-05 the latest version is from 24 March]

  • (./) 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 (filed as #917535 and #917536)
  • (./) Have FTP masters create security + backports archive for upcoming release( (filed as #917537)

    • 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 (requested in RT #7718)

    • Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run)
  • (./) Have DSA upgrade a buildd for each architecture (requested in RT #7720)

    • 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 (mail) (requested in RT #7719)

    • 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@
      • [elbrus, 2019-04-05] first mails send.

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 https://lists.debian.org/20190425081109.6ad2d0b226cf3d1c9fb3e523@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:

    • 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:

  • (./) 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 Releasing

Mention things that are happening on IRC so the publicity team can relay to social media

After the release