Differences between revisions 22 and 23
Revision 22 as of 2017-03-19 11:50:18
Size: 5969
Comment:
Revision 23 as of 2017-03-26 11:04:49
Size: 5972
Editor: NielsThykier
Comment: Mark 3 more items as done
Deletions are marked like this. Additions are marked like this.
Line 28: Line 28:
 * [ ] Have FTP masters create security + backports archive for upcoming release
 * [ ] Have DSA upgrade a non-critical machine
 * (./) Have FTP masters create security + backports archive for upcoming release
 * (./) Have DSA upgrade a non-critical machine
Line 47: Line 47:
 * [ ] d-i should have (beta or even better rc) releases  * (./) d-i should have (beta or even better rc) releases

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

The following things need to be done for the Stretch release:

Tagging RC Bugs

At some point, we will have to tag the remaining RC bugs to filter what should be removed/deferred/fixed. The usertagged bugs will be listed on:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian.org@packages.debian.org;tag=stretch-can-defer;tag=stretch-will-remove;tag=stretch-is-blocker;ordering=stretch-sort

Actions to do before the freeze

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

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

  • (./) Prepare the website changes

    • (./) Ensure that the following pages exist on debian.org/releases/<RELEASENAME>

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

    • (./) Assert the architecture list is up to date (release.data), new ports should be available on https://debian.org/ports (ports/index.wml)

  • (./) Decide on Release Architectures

  • (./) Have FTP masters create security + backports archive for upcoming release

  • (./) Have DSA upgrade a non-critical machine

    • {i} Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run)

  • [ ] Have DSA upgrade a buildd for each architecture
    • kvm/virtual (upgrade or create new vm)
      • [ ] all
      • [ ] amd64/i386
      • [ ] arm64 (some of them, they could probably also build armhf)
      • [ ] ppc64el
    • bare metal
      • [ ] arm64 (some of them are bare metal)
      • [ ] armel/armhf
      • [ ] mips
      • [ ] mipsel/mips64el
      • [ ] s390x (not virtual from the DSA point of view)

Before the 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.
  • [ ] Website:
    • [ ] Have a patch ready for template/debian/release_info.wml to update the current release. This is to be deployed during the release.
  • [ ] Install Guide should be up-to-date
  • [ ] ReleaseNotes need to be updated:

    • [ ] ?KernelTeam signoff for specials with the Kernel

    • [ ] d-i team signoff for specials with this update (check esp. if old versions of d-i should be purged if new versions enter $suite's d-i area)
    • [ ] Security Team signoff for lower supported packages

    • [ ] Coordinate with translators
  • [ ] Install & upgrade tests should reveal no undocumented (release notes, install guide) surprises

  • [ ] Coordinate date with the FTP-Team
    • {i} Have an FTP-master ready/notified/available 3 weeks before the Release

  • [ ] Ensure the planned release date is on debian.org/releases
  • [ ] Send the preparation mail.
  • [ ] 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

During the actual Release

  • [ ] 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 moved
    • new win32-loader?
    • cleanup of $codename-proposed-updates and $codename-security
    • stable-updates needs its suite name hack updated to oldstable-updates
  • [ ] 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@lists.debian.org as people tend to cry occassionally

  • [ ] 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
  • [ ] Update the wiki (coordinated with ReleaseNotes's editor)

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