1712
Comment:
|
10296
notify web team & users
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
<!> This is a RM's TODO list, which might not be authorative or complete. | <!> This is template of the RM's TODO list, which might not be authorative or complete. * [[/BusterCheckList|Buster TODO list]] * [[/StretchCheckList|Stretch TODO list]] |
Line 5: | Line 9: |
== 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 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: [[https://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: * [[https://bugs.debian.org/424427|#424427: [bts] should support usercategory]] * [[Devscripts/bugs]] == Before freeze == * Decide on a code name for ''<codename>+2'' * Get that included in BTS tags: * @gTags in /srv/bugs.debian.org/etc/config on bugs-master.debian.org * bts_release_tags and bts_release_ignore_tags [[https://anonscm.debian.org/viewvc/webwml/webwml/english/Bugs/pkgreport-opts.inc?view=markup#l176|in webwml]] * Edit wiki pages to add the new release: ReleaseParty DebianReleases Debian<RELEASENAME> Debian<RELEASENAME-1> NewIn<RELEASENAME> 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/<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) * Ensure that updates to the installation-guide appear on the website (d-i) [To avoid a repeat of <<mid(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) * FTP-masters generate several (see <<mid(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 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 * Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run) * Have DSA upgrade a buildd for each architecture * Do a checklist for each architecture/buildd machine * Have DSA contact DebianList:debian-services-admin to ask service maintainers to prepare their services for the new release ([[https://lists.debian.org/msgid-search/1477278955.2136.1.camel@debian.org|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@ |
|
Line 6: | Line 71: |
* 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 DVD making dry run with the right installer, to ensure that everything fits properly. * Install Guide should be up-to-date |
Line 9: | Line 77: |
* Check with KernelTeam for specials with the Kernel | * Check with [[Teams/DebianKernel|Linux kernel team]] for specials with the Kernel |
Line 11: | Line 79: |
* Coordinate with translators * Coordinate date with the FTP-Team * Have an FTP-master ready/notified/available 3 weeks before the Release * Notify the SecurityTeam of an upcoming Release * Notify the PressTeam of an upcoming Release * Notify the Debian-CD team of an upcoming Release |
* Check with [[Teams/Security|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. * Website: * Have a patch ready for template/debian/release_info.wml to update * Notify the [[Teams/Security|Security 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 100: |
* Prepare PressAnnouncement | * Notify the [[Teams/Publicity|publicity]] team of an upcoming Release * Prepare [[Teams/Publicity/Announcements|press release]] |
Line 21: | Line 104: |
* Prepare the website changes | |
Line 24: | Line 106: |
* Mention things that are happening on IRC so the [[Teams/Publicity|publicity]] team can [[Teams/Publicity/Release|relay]] to social media |
|
Line 26: | Line 110: |
* new win32-loader? * cleanup of $codename-proposed-updates and $codename-security * stable-updates needs its suite name hack updated to oldstable-updates * debtags need to be copied from unstable |
|
Line 27: | Line 115: |
* Check if /org/ftp.debian.org/ftp/README was updated. | * Check if /srv/ftp.debian.org/ftp/README was updated. |
Line 30: | Line 118: |
* Notify debian-security@lists.debian.org as people tend to cry occassionally * 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 [[mailto:debian-security@lists.debian.org|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 [[Teams/DebianCd|Debian CD]] Team that the Release is done |
Line 36: | Line 124: |
* Update the wiki (coordinated with ReleaseNotes's editor) | * 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 [[http://www.debian.org/releases/|release pages]] * Update Wiki: * Update these wiki pages (coordinated with ReleaseNotes's editor): FrontPage DebianReleases DebianReleases/PointReleases DebianTesting DebianStable DebianOldStable [[Status/Stable]] StableUpdates StableProposedUpdates [[Backports]] [[Welcome/Users]] [[Glossary]] [[Debian<RELEASENAME>]] [[Debian<RELEASENAME-1>]] [[Debian<RELEASENAME+1>]] ReleaseParty [[ReleaseParty<RELEASENAME>]] [[ReleaseParty<RELEASENAME+1>]] [[DebianArt/Themes]] [[DebianDesktop/Artwork]] [[DebianDesktop/Artwork/<RELEASENAME+1>]] [[ArchiveQualification/<RELEASENAME+1>]] [[Teams/DebianCD/ReleaseTesting]] [[Teams/Dpkg/FAQ]] * Ping the wiki team to run /srv/wiki.debian.org/bin/get-debian-suite-info |
Line 38: | Line 134: |
* 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]], [[https://freshcode.club/|fresh(code)]] * [[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]] * Update the [[https://www.debian.org/doc/misc-manuals#history|Project History]] document and upload to stable-p-u * Notify [[Derivatives/CensusQA#release|derivatives]] about the release * Update all the places that [[SuitesAndReposExtension#Existing_hardcoding|hardcode]] suite names or codenames * 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 [[https://www.debian.org/users/|Debian users]] after a few months to check if they are still using Debian and to update their testimonials * 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 dinstall run smoothly * ... |
This is template of the 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 request@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:
Useful references about this feature are:
Before freeze
Decide on a code name for <codename>+2
- Get that included in BTS tags:
- @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 Debian<RELEASENAME> Debian<RELEASENAME-1> ?NewIn<RELEASENAME> Glossary
Edit/add deb.li pages to add the new release: relparty <RELEASENAME> get<RELEASENAME>
- Get that included in BTS tags:
- 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)
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)
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 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
- Suggestions include: lindsay.debian.org (the host doing the lintian archive-wide run)
- 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 new 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@
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
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 $suite'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)
- Required
- 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:
- 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
Prepare press release
- 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
- debtags need to be copied from unstable
- 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 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 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:
Update these wiki pages (coordinated with ReleaseNotes's editor): FrontPage DebianReleases DebianReleases/PointReleases DebianTesting DebianStable DebianOldStable Status/Stable StableUpdates StableProposedUpdates Backports Welcome/Users Glossary ?Debian<RELEASENAME> ?Debian<RELEASENAME-1> ?Debian<RELEASENAME+1> ReleaseParty ?ReleaseParty<RELEASENAME> ?ReleaseParty<RELEASENAME+1> DebianArt/Themes DebianDesktop/Artwork ?DebianDesktop/Artwork/<RELEASENAME+1> ?ArchiveQualification/<RELEASENAME+1> Teams/DebianCD/ReleaseTesting Teams/Dpkg/FAQ
- Ping the wiki team to run /srv/wiki.debian.org/bin/get-debian-suite-info
- 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
Notify Distrowatch; send a mail to distro@distrowatch.com
Notify LWN, slashdot, Hacker News, Reddit, fresh(code)
Propose a tweet/dent 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
Update all the places that hardcode suite names or codenames
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
- 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 dinstall run smoothly
- ...