Differences between revisions 1 and 32 (spanning 31 versions)
Revision 1 as of 2010-10-02 10:58:46
Size: 1712
Editor: MehdiDogguy
Comment:
Revision 32 as of 2015-08-31 17:43:12
Size: 5761
Editor: NielsThykier
Comment: Add some "Before freeze" ideas
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
== 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 codename-sort
  * Codename [tag=]
    + Blockers for Codename [codename-is-blocker]
    + Planned for removal [codename-will-remove]
    + Ignored for Codename [codename-can-defer]
}}}

Then, usertagged bugs will be listed on:

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

Useful references about this feature are:
 * [[http://bugs.debian.org/424427|#424427: [bts] should support usercategory]]
 * [[Devscripts/bugs]]

== Before freeze ==

 * Decide on a code name for ''<codename>+2''
 * Theme (artwork) design should be finalised and decided
 * Prepare the website changes
   * Ensure the planned release date is on debian.org/releases
   * 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)
   * Have a patch ready for template/debian/release_info.wml to update the current release. This is to be deployed during the release.
 * Decide on Release Architectures
 * Have FTP masters create security + backports archive for upcoming release
 * Have DSA upgrade a non-critical machine
   * Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run)
 * Have DSA upgrade a buildd for each architecture
Line 6: Line 50:
 * Send the preparation mail.
   * Send a mail to the Press team

 * 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 CD making dry run with the right installer, to ensure that everything fits properly.
 * Install Guide should be up-to-date
Line 11: Line 58:
   * Check with [[Teams/Security|Security Team]] for lower supported packages
Line 12: Line 60:
 * Install & upgrade tests should reveal no undocumented (release notes, install guide) surprises
Line 14: Line 63:
 * Notify the SecurityTeam of an upcoming Release  * Send the preparation mail.
   * Send a mail to the Press team
* Notify the [[Teams/Security|Security Team]] of an upcoming Release
Line 16: Line 67:
 * Notify the Debian-CD team of an upcoming Release  * Notify the [[Teams/DebianCd|Debian CD]] team of an upcoming Release
 * Notify the DebianLive Team of an upcoming Release
Line 18: Line 70:
 * Notify the [[Teams/Publicity|publicity]] team of an upcoming Release
Line 21: Line 74:
 * Prepare the website changes
Line 24: Line 76:

 * Mention things that are happening on IRC so the [[Teams/Publicity|publicity]] team can relay to social media
Line 26: Line 80:
   * new win32-loader?
   * cleanup of $codename-proposed-updates and $codename-security
   * stable-updates needs its suite name hack updated to oldstable-updates
Line 27: Line 84:
 * Check if /org/ftp.debian.org/ftp/README was updated.  * Check if /srv/ftp.debian.org/ftp/README was updated.
Line 31: Line 88:
 * Notify the PressTeam, that Release is done (tell them when the Release will be pushed out)
 * Notify the DebianCD Team that the Release is done
 * Notify the Press Team, that Release is done (tell them when the Release will be pushed out)
 * Notify the [[Teams/DebianCd|Debian CD]] Team that the Release is done
Line 38: Line 95:
 * 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 ==

 * Notify Distrowatch; send a mail to distro@distrowatch.com
 * Notify [[https://lwn.net/op/FAQ.lwn#contact|LWN]], [[http://slashdot.org/submission|slashdot]], [[https://news.ycombinator.com/|Hacker News]], [[http://www.reddit.com/r/debian|Reddit]]
 * [[Teams/Publicity/Identica|Propose]] a tweet/dent on the [[irc://irc.debian.org/debian-publicity|#debian-publicity]] [[IRC]] channel
 * Blog about release team experiences
 * Bits from the release team mail
 * Update the [[Teams/Publicity/Timeline|Debian timeline]]
 * Notify [[Derivatives/CensusQA#release|derivatives]] about the release
 * Update all the places that [[SuitesAndReposExtension#Existing_hardcoding|hardcode]] suite names or codenames

<!> This is a RM's TODO list, which might not be authorative 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 ?control@bugs.debian.org:

user release.debian.org@packages.debian.org
usercategory codename-sort
  * Codename [tag=]
    + Blockers for Codename [codename-is-blocker]
    + Planned for removal [codename-will-remove]
    + Ignored for Codename [codename-can-defer]

Then, usertagged bugs will be listed on:

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

Useful references about this feature are:

Before freeze

  • Decide on a code name for <codename>+2

  • Theme (artwork) design should be finalised and decided
  • Prepare the website changes
    • Ensure the planned release date is on debian.org/releases
    • 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)

    • Have a patch ready for template/debian/release_info.wml to update the current release. This is to be deployed during the release.
  • Decide on Release Architectures
  • Have FTP masters create security + backports archive for upcoming release
  • Have DSA upgrade a non-critical machine
    • Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run)
  • Have DSA upgrade a buildd for each architecture

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 CD making dry run with the right installer, to ensure that everything fits properly.
  • Install Guide should be up-to-date
  • ReleaseNotes need to be updated:

    • Check with ?KernelTeam 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 $suite's d-i area)
    • Check with Security Team 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
    • Have an FTP-master ready/notified/available 3 weeks before the Release
  • Send the preparation mail.
    • Send a mail to the Press team
  • Notify the Security Team of an upcoming Release

  • Notify the ?PressTeam 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 ?PressAnnouncement

    • coordinate with d-i team for text for d-i changes
  • Prepare the wiki changes

While the 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 Press 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