NewReleaseCycleProcess

Differences between revisions 1 and 210 (spanning 209 versions)
⇤ ← Revision 1 as of 2007-09-17 17:53:43 →
Size: 4371
Editor: 82-69-40-219
Comment: moved from Canonical wiki
← Revision 210 as of 2020-05-27 00:20:39 → ⇥
Size: 15178
Editor: brian-murray
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
To be carried out by: Adam Conrad and Ubuntu Release Manager <<TableOfContents>>
Line 3: Line 3:
Goals: To be carried out by: Ubuntu Release Team

== Goals ==
Line 8: Line 10:
Previous release minus 1 month: == Stages ==
Line 10: Line 12:
 1. Contact Soyuz development/production teams to ensure that they will be ready to create the new distrorelease on time. Bugs related to this process are tagged with [[https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=new-release-cycle-process|new-release-cycle-process]]. If you discover new glitches or things that can be automated, please file a bug with that tag.

=== Previous release minus 1 month ===

 1. Contact Soyuz development/production teams to ensure there are no known outstanding issues that will prevent on-time opening of the new distroseries.
 1. If there is a release scheduled to End of Life, start off EndOfLifeProcess for it.
Line 12: Line 19:
 1. Confirm final schedule for the new release and communicate key release dates
  * Create codenameReleaseSchedule page
  * Update ReleaseSchedule
  * Update Fridge calendar?
  * Canonical calendars
Line 13: Line 25:
Previous release minus 2 weeks: === Previous release minus 2 weeks ===
Line 16: Line 28:
 1. File an RT ticket asking for distrorelease-changes to be set up.  1. Ask for the maillist distroseries-changes to be set up by sending email to ubuntu-platform@rt.canonical.com to file an RT ticket.
  * Note that this requires [[https://wiki.canonical.com/InformationInfrastructure/SA/ListCreation#Ubuntu.27s_.3Crelease.3E-changes_lists|special configuration]].
 1. Subscribe gmane to distroseries-changes mailing list, once it's available.
Line 18: Line 32:
Previous release plus 1 day: === Previous release plus 1 day ===
Line 20: Line 34:
 1. Notify a Launchpad admin to create new distrorelease with status `FROZEN`.
 1. Create a milestone named `ubuntu-$version` in the release
 1. Create new seed branches based on those for the previous release, and push them to the appropriate subdirectories of `sftp://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/`.
 1. Notify Colin Watson to set up seed mirrors and germinate output for the new distrorelease.
 1. Reject any queued uploads to `RELEASE` pocket of previous distrorelease.		  1. Create new seed branches based on those for the previous release, and push them to the appropriate subdirectories of `git+ssh://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git`. The `branch-seeds` script in [[https://code.launchpad.net/+branch/ubuntu-archive-tools|lp:ubuntu-archive-tools]] can do the hard work here.
 1. Notify Colin Watson to set up seed mirrors and germinate output for the new distroseries.
Line 26: Line 37:
 1. Check that the new distrorelease exists with status `FROZEN`, and that the previous distrorelease has status `CURRENT`.
 1. Notify Soyuz production team to run `lp_publish:$ LPCONFIG=ftpmaster ./scripts/ftpmaster-tools/initialise-from-parent.py <new-distrorelease-name>` on drescher (takes around 8 minutes).
 1. Run the publisher once: `lp_publish:$ LPCONFIG=ftpmaster ./scripts/publish-distro.py -d ubuntu -vv -A -s DRN -s DRN-updates -s DRN-security -s DRN-proposed -s DRN-backports` where DRN is the new distrorelease name. This run will create the proper archive indexes for all suites (takes around 25 minutes).
 1. Compare `dists` trees for previous and current distrorelease and sign off on any differences; the only differences should be the distrorelease name.
  * `~ubuntu-archive/bin/compare-archives` or other tools may be useful for this - XXX nominate one and install in a standard location on drescher
 1. Verify hard-coded parameters in Soyuz shell-scripts: './cronscripts/publishing/cron.germinate' and './cronscripts/publishing/gen-contents/generate-contents'.
 1. Re-enable the Soyuz publisher cron jobs.
 1. Notify Colin Watson to modify various reports (`britney`, `anastacia`, `jessica`) to point to the new distrorelease.
 1. Notify Scott James Remnant to set up `merge-o-matic` to point to the new distrorelease.		  1. Notify a Launchpad admin to create new distroseries with status `FROZEN`.
 1. Create milestones in the new series:
  * `ubuntu-$version-month-1` etc., set at monthly intervals after the previous release until feature freeze
  * `ubuntu-$version-feature-freeze` at feature freeze
  * `ubuntu-$version-beta` or `ubuntu-$version-beta-1` etc. as required
  * `ubuntu-$version` at the next release date
 1. Check that the new distroseries exists with status `FROZEN`, and that the previous distroseries has status `CURRENT`.
 1. Visit http://launchpad.net/ubuntu/<series> and click "Initialize Series" in the top right menu. Select which Debian parents you want for this series (it defaults to the existing ones), which architectures you want, ensure "Copy Source And Binaries" is selected and click the "Initialize Series" button.
 1. Re-enable the Soyuz publisher cron job for a single publisher run.
 1. Add the new series name to the [[https://launchpad.net/ubuntu/+manage-official-tags|official Launchpad bug tags]], and add `verification-needed-PREVIOUS` and `verification-done-PREVIOUS` where `PREVIOUS` is the name of the previous series.
 1. Ask #webops to run "ANALYZE sourcepackagepublishinghistory; ANALYZE binarypackagepublishinghistory;" on launchpad_prod.
 1. Re-enable the Soyuz publisher cron job for a second publisher run.
 1. As `ubuntu-archive@snakefruit`, use `compare-archives` to compare `dists` trees under `~/mirror/ubuntu/` for previous and current distroseries and sign off on any differences; the only differences should be the distroseries name, that custom uploads (`installer-*`, `dist-upgrader-all`, and `i18n`) are missing from `dists/DSN/main`, that `Release.gpg` does not yet exist (this will be created when the full publisher cron job next runs), and that `Contents-*.gz` do not yet exist (these will be created when `generate-contents` next runs).
 1. Notify Iain Lane (Laney) to run through https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Opening_up_a_new_series
 1. Initialise the `partner` repository on `archive.canonical.com` for the new series. Either:
  * copy packages forward from `partner` for the previous series (use `curl -s http://archive.canonical.com/dists/PREVIOUS/partner/source/Sources.xz | xzcat | grep-dctrl -sPackage,Version ''` to list the contents, and `copy-package --from ubuntu/partner --from-suite PREVIOUS --to-suite NEW --include-binaries --auto-approve SOURCE` to copy individual source packages); or
  * tell Launchpad to create it even though it's empty (`mark-suite-dirty -A ubuntu/partner -s NEW`).
 1. Grant ~ubuntu-sru queue admin access to the previous distroseries (`for pocket in proposed updates; do edit-acl -p ubuntu-sru -S PREVIOUS --pocket $pocket -t admin add; done`) and remove ~ubuntu-release's queue admin access (`for pocket in release proposed; do edit-acl -p ubuntu-release -S PREVIOUS --pocket $pocket -t admin delete; done`).
 1. Check that the process of initialising the new distroseries granted queue admin access to ~ubuntu-release to the new distroseries (`edit-acl -p ubuntu-release -S NEW -t admin query`).
 1. Move the bootstrap archive on snakefruit to use the new series, so the new chroots can reference it.
 1. Notify Adam Conrad to upload new buildd chroots (which can be copied from the previous distroseries), and to upload fresh tarballs for the just-released distroseries as well for efficiency.
 1. Once chroots exist, as lp_buildd@pepo, run `/srv/launchpad.net/production/launchpad/scripts/add-missing-builds.py -s NEW-proposed` plus `-a ARCH` for each architecture in NEW (Adam Conrad and Colin Watson have access, or ask IS).
 1. [[https://answers.launchpad.net/launchpad/+addquestion|Add a request to Launchpad devs and admins]] to open Launchpad translations for the new distroseries.
 1. Modify various reports on snakefruit (at least `britney`) to point to the new distroseries.
 1. Notify Colin Watson to set up `merge-o-matic` to point to the new distroseries.
 1. Update `global.conf` in `lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs`
Line 36: Line 64:
 1. Notify a Launchpad admin to set the status of the new distrorelease to `DEVELOPMENT`.  1. Make sure that proposed-migration is configured properly for the new series.
   1. Check that `https://people.canonical.com/~ubuntu-archive/proposed-migration/<NEWSERIES>/results.cache` exists, as required by bileto.
 1. Remove the "block-all source" hint from proposed-migration.
 1. Notify a Launchpad admin to set the status of the new distroseries to `DEVELOPMENT`.
Line 38: Line 69:
 1. Create `data/RELEASE`, `tools/RELEASE`, and `tools/boot/RELEASE` directories in `debian-cd` based on corresponding directories for the previous release. Set `OFFICIAL` to "Alpha" in `CONF.sh` for the new release. Adjust `cdimage` code to be aware of the new release.  1. Check whether there are any uploads in the previous release's -updates pocket not in the new release, and copy them over if so.
 1. Copy everything from PREVIOUS-proposed to DEVEL-proposed, and delete the ones from PREVIOUS-proposed that aren't SRUs.
 1. Inform the SRU team that the bulk copy has been done, so that they know to sort out PREVIOUS-proposed vs. DEVEL-proposed for any new SRUs they accept.
 1. Drop the `--dry-run` flag from the `auto-sync` job in `ubuntu-archive@snakefruit`'s crontab.
 1. Contact owners of each image with seeded snaps to have snap channels opened and closed for the new release.
 1. Create new live filesystem configurations for the new distroseries, using `branch-livefses` in [[https://code.launchpad.net/+branch/ubuntu-archive-tools|lp:ubuntu-archive-tools]]. This currently needs to be done for OWNER where OWNER is:
  * ubuntu-cdimage
  * cloudware
  * cloud-images-release-managers
 1. Create `data/RELEASE`, `tools/RELEASE`, and `tools/boot/RELEASE` directories in `debian-cd` based on corresponding directories for the previous release. Set `OFFICIAL` to "Alpha" in `CONF.sh` for the new release.
 1. Adjust `cdimage` code to be aware of the new release, and configure ~cdimage/.isotracker.conf
 1. Notify stgraber, vorlon, or bdmurray to follow README.series on db@limequat (the ISO tracker database).
 1. Notify Michael Vogt to update the default release in popcon.ubuntu.com and update the component list
 1. Target issues from the previous release's release notes to be fixed in the new release.
 1. Notify Brian Murray or a real ~ubuntu-archive member to create an Apport retracer apt configuration ([[http://bazaar.launchpad.net/~ubuntu-archive/apport/lp-retracer-config/revision/30|example for 17.04]]) for the new release and roll it out to porter-i386:/home/ubuntu-archive/config
 1. Check http://ddebs.ubuntu.com for the new release. (In principle that should happen by itself, but in practice it may crash/hang on archive.ubuntu.com not yet having indexes, or run into time outs on the gigantic first import after opening/copying the new release). This is running on `numen.canonical.com` → `sudo -u ddebs -i`; This has a checkout of [[http://bazaar.launchpad.net/~ubuntu-archive/ddeb-retriever/trunk/|lp:ddeb-retriever]] and is cron driven.
 1. Notify Iain Lane or someone with access to the user update config.json to add the new release to the list in git lp:~ubuntu-desktop/+git/appstream-cloud (*make sure the json is valid*), and then as prod-ue-appstream-back@wendigo run `juju set appstream-generator config="$(cat config.json)"` after pulling. See `9163c1a2bc5fb3c2c2ba1c27df8f7573a54b4045`.
 1. Open an RT to ask IS to create chroots on the porter boxes.
 1. Notify William Grant to update the ftbfs on qa.ubuntuwire.com.
 1. Notify Rhonda D'Vine (Rhonda) to update packages.ubuntu.com.
 1. Notify Iain Lane (Laney) to update people.c.c/~ubuntu-archive/transitions and udd.debian.org
 1. Notify Josh Powers (or anybody in ~canonical-server) to update lp:ubuntu-manpage-repository
 1. Notify Brian Murray to update whoopsie-update-daily-users cronjob in the retracer charm owned by the daisy-pluckers team to include the new release of Ubuntu.
 1. Notify Brian Murray to update the Ubuntu Error Tracker for the new release of Ubuntu e.g. [[https://bazaar.launchpad.net/~daisy-pluckers/errors/trunk/revision/600|errors change]] and [[https://bazaar.launchpad.net/~daisy-pluckers/daisy/trunk/revision/828|daisy change]]
 1. Notify someone with access to the "prod-cnf-extractor" group to enable generation of `command-not-found` indices (`juju config cnf-extractor releases="space separated list of releases"`)

=== First weeks, after toolchain complete ===

 1. Notify 'ubuntu-devel' and 'ubuntu-devel-announce' that the release is now open and where to subscribe to the release'-changes' maillist.
 1. Review the people listed in '!regression-alert' ([[https://wiki.ubuntu.com/StableReleaseUpdates#Regressions|StableReleaseUpdates#Regressions]]) as needed. '!regression-alert' is handled by [[https://wiki.ubuntu.com/IRC/Bots|ubotto]] and flagged in #ubuntu-devel. Changes can be made and tested in #ubuntu-ops. The people listed should be the tech leads for foundations, desktop, server, security, and QA, along with the release manager and key community members.
 1. Merge `base-files` if necessary and change `/etc/issue`, `/etc/issue.net`, `/etc/lsb-release`, and `/etc/os-release` to refer to the new release.
 1. Merge `debootstrap` if necessary and create a bootstrap script for the new release as a copy of the previous one (currently, we can just make the new one a symlink to `gutsy`, as it hasn't changed since then).
 1. Merge `lintian`, `vim`, `emacs-goodies-el` and `clang` if necessary and update lists of Ubuntu release names to include the new release name.
 1. Do a no change rebuild of devscripts to pick up the new development release from distro-info.
 1. Do a no change rebuild of app-install-data-partner.
 1. Update `/usr/share/python-apt/templates/Ubuntu.info` in `python-apt` to include the new release name.
 1. Update `ubuntu-release-upgrader` to handle the new release e.g. https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/3181 and DistUpgradeQuirks e.g. https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/3232.
 1. Update `meta-release` to handle the new release e.g. https://bazaar.launchpad.net/~ubuntu-core-dev/meta-release/ubuntu/revision/247.
 1. Update `auto-upgrade-testing-specifications` so that upgrade testing is done to the new release e.g. https://bazaar.launchpad.net/~canonical-platform-qa/auto-upgrade-testing-specifications/auto-upgrade-testing-specifications/revision/46.
 1. Update `syslinux-themes-ubuntu` to handle the new release.
 1. Merge `cdrom-detect`, `choose-mirror`, and `iso-scan` if necessary and update `cdrom/suite` and `mirror/suite` debconf templates to include a choice for the new release and update any previous default.
 1. Merge the rest of the installer in dependency order, ending with `debian-installer` once all other installer components have built successfully on all architectures.
 1. Notify `ubiquity` maintainer(s) to run `debian/rules update`, adjust as necessary to account for changes, and upload.
 1. Ensure that `postgresql-common` is updated for new release
 1. Update the version number in `unity-greeter` & `unity-control-center` logos to refer to the new release
 1. Ensure that the ISO tracker has a daily-build "milestone" for the new release
 1. Create `~ubuntu-archive/wubi/RELEASE/` and symlink `~ubuntu-archive/wubi/RELEASE-1/stable` to `~ubuntu-archive/wubi/RELEASE/stable`
 1. Edit `default_milestone` in `~cdimage/.isotracker.conf` to match the new milestone name in the ISO tracker
 1. Notify canonical-platform-qa (qa-team@lists.canonical.com) to set up Utah jobs for Ubuntu desktop and server.
 1. Add new series to `production/current-triggers` on nusakan.
Line 40: Line 120:
 1. Update UbuntuWiki:UbuntuDevelopment to reflect the code name of the current release  1. Add the date of the previous release to `calendar.ubuntu` in `bsdmainutils`
 1. Defect Analysts (or team lead for those teams without Defect Analysts) will triage the {{{+nominations}}} bugs list, declining non-SRU candidate nominations and re-target bugs. The release team will evaluate the remaining list, accepting good SRU candidates
 1. Notify web team to reset http://www.ubuntu.com/testing to indicate no testing in progress, and reference new release.
 1. Check to make sure the future+1 and future+2 series is available on launchpad to assign bugs to, if not present, then ask webops on #launchpad-ops to add letter-series, with status Future.
 1. Update https://wiki.ubuntu.com/ReleaseTeam/FeatureStatus to new release, and all linked pages.
 1. Two weeks after new release starts, finish EndofLifeProcess for any old releases scheduled now that we've had some migration overlap.
 1. Update ubuntu-release-notes project to know about the new series.
 1. Ask `firefox` maintainer to update start page for the new release.
 1. Contact flavours to confirm their ongoing participation in the new release, and verify that the contact in the ISO tracker is still accurate.
 1. Continue on MilestoneProcess.
Line 42: Line 131:
First weeks, after toolchain complete:

 1. Merge `base-files` if necessary and change `/etc/issue`, `/etc/issue.net`, `/etc/motd`, and `/etc/lsb-release` to refer to the new release.
 1. Merge `debootstrap` if necessary and create a bootstrap script for the new release as a copy of the previous one.
 1. Merge `devscripts`, `lintian`, and `vim` if necessary and update lists of Ubuntu release names to include the new release name.
 1. Merge `cdrom-detect`, `choose-mirror`, and `iso-scan` if necessary and update `cdrom/suite` and `/mirror/suite` debconf templates to include a choice for the new release and update any previous default.
 1. Merge the rest of the installer in dependency order, ending with `debian-installer` once all other installer components have built successfully on all architectures.
 1. Notify `oem-config` and `ubiquity` maintainer(s) to run `debian/rules update`, adjust as necessary to account for changes, and upload.
 1. Upload a new version of WinFOSS with new version numbers (heno)
 1. Continue on MilestoneProcess.		 ----
CategoryProcess

Contents

  1. Goals
  2. Stages
    1. Previous release minus 1 month
    2. Previous release minus 2 weeks
    3. Previous release plus 1 day
    4. First weeks, after toolchain complete

To be carried out by: Ubuntu Release Team

Goals

  • Unblock development process for new release as quickly as possible.
  • Prepare for first milestone CD release.

Stages

Bugs related to this process are tagged with new-release-cycle-process. If you discover new glitches or things that can be automated, please file a bug with that tag.

Previous release minus 1 month

  1. Contact Soyuz development/production teams to ensure there are no known outstanding issues that will prevent on-time opening of the new distroseries.

  2. If there is a release scheduled to End of Life, start off EndOfLifeProcess for it.

  3. Remind toolchain developers to begin preparing the new toolchain.
  4. Confirm final schedule for the new release and communicate key release dates
    • Create codenameReleaseSchedule page

    • Update ReleaseSchedule

    • Update Fridge calendar?
    • Canonical calendars

Previous release minus 2 weeks

  1. Double-check with Soyuz development/production teams.

  2. Ask for the maillist distroseries-changes to be set up by sending email to ubuntu-platform@rt.canonical.com to file an RT ticket.

  3. Subscribe gmane to distroseries-changes mailing list, once it's available.

Previous release plus 1 day

  1. Create new seed branches based on those for the previous release, and push them to the appropriate subdirectories of git+ssh://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git. The branch-seeds script in lp:ubuntu-archive-tools can do the hard work here.

  2. Notify Colin Watson to set up seed mirrors and germinate output for the new distroseries.
  3. Disable the Soyuz publisher cron jobs.

  4. Notify a Launchpad admin to create new distroseries with status FROZEN.

  5. Create milestones in the new series:

    • ubuntu-$version-month-1 etc., set at monthly intervals after the previous release until feature freeze

    • ubuntu-$version-feature-freeze at feature freeze

    • ubuntu-$version-beta or ubuntu-$version-beta-1 etc. as required

    • ubuntu-$version at the next release date

  6. Check that the new distroseries exists with status FROZEN, and that the previous distroseries has status CURRENT.

  7. Visit http://launchpad.net/ubuntu/<series> and click "Initialize Series" in the top right menu. Select which Debian parents you want for this series (it defaults to the existing ones), which architectures you want, ensure "Copy Source And Binaries" is selected and click the "Initialize Series" button.

  8. Re-enable the Soyuz publisher cron job for a single publisher run.

  9. Add the new series name to the official Launchpad bug tags, and add verification-needed-PREVIOUS and verification-done-PREVIOUS where PREVIOUS is the name of the previous series.

  10. Ask #webops to run "ANALYZE sourcepackagepublishinghistory; ANALYZE binarypackagepublishinghistory;" on launchpad_prod.
  11. Re-enable the Soyuz publisher cron job for a second publisher run.

  12. As ubuntu-archive@snakefruit, use compare-archives to compare dists trees under ~/mirror/ubuntu/ for previous and current distroseries and sign off on any differences; the only differences should be the distroseries name, that custom uploads (installer-*, dist-upgrader-all, and i18n) are missing from dists/DSN/main, that Release.gpg does not yet exist (this will be created when the full publisher cron job next runs), and that Contents-*.gz do not yet exist (these will be created when generate-contents next runs).

  13. Notify Iain Lane (Laney) to run through https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Opening_up_a_new_series

  14. Initialise the partner repository on archive.canonical.com for the new series. Either:

    • copy packages forward from partner for the previous series (use curl -s http://archive.canonical.com/dists/PREVIOUS/partner/source/Sources.xz | xzcat | grep-dctrl -sPackage,Version '' to list the contents, and copy-package --from ubuntu/partner --from-suite PREVIOUS --to-suite NEW --include-binaries --auto-approve SOURCE to copy individual source packages); or

    • tell Launchpad to create it even though it's empty (mark-suite-dirty -A ubuntu/partner -s NEW).

  15. Grant ~ubuntu-sru queue admin access to the previous distroseries (for pocket in proposed updates; do edit-acl -p ubuntu-sru -S PREVIOUS --pocket $pocket -t admin add; done) and remove ~ubuntu-release's queue admin access (for pocket in release proposed; do edit-acl -p ubuntu-release -S PREVIOUS --pocket $pocket -t admin delete; done).

  16. Check that the process of initialising the new distroseries granted queue admin access to ~ubuntu-release to the new distroseries (edit-acl -p ubuntu-release -S NEW -t admin query).

  17. Move the bootstrap archive on snakefruit to use the new series, so the new chroots can reference it.
  18. Notify Adam Conrad to upload new buildd chroots (which can be copied from the previous distroseries), and to upload fresh tarballs for the just-released distroseries as well for efficiency.

  19. Once chroots exist, as lp_buildd@pepo, run /srv/launchpad.net/production/launchpad/scripts/add-missing-builds.py -s NEW-proposed plus -a ARCH for each architecture in NEW (Adam Conrad and Colin Watson have access, or ask IS).

  20. Add a request to Launchpad devs and admins to open Launchpad translations for the new distroseries.

  21. Modify various reports on snakefruit (at least britney) to point to the new distroseries.

  22. Notify Colin Watson to set up merge-o-matic to point to the new distroseries.

  23. Update global.conf in lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs

  24. Notify toolchain developers to upload new toolchain. Iterate uploads as necessary until this has successfully built on all architectures.
  25. Make sure that proposed-migration is configured properly for the new series.

    1. Check that https://people.canonical.com/~ubuntu-archive/proposed-migration/<NEWSERIES>/results.cache exists, as required by bileto.

  26. Remove the "block-all source" hint from proposed-migration.

  27. Notify a Launchpad admin to set the status of the new distroseries to DEVELOPMENT.

  28. Inform #ubuntu-devel and ubuntu-devel-announce that the new release is now open for uploads, pointing to merge-o-matic output.

  29. Check whether there are any uploads in the previous release's -updates pocket not in the new release, and copy them over if so.
  30. Copy everything from PREVIOUS-proposed to DEVEL-proposed, and delete the ones from PREVIOUS-proposed that aren't SRUs.
  31. Inform the SRU team that the bulk copy has been done, so that they know to sort out PREVIOUS-proposed vs. DEVEL-proposed for any new SRUs they accept.

  32. Drop the --dry-run flag from the auto-sync job in ubuntu-archive@snakefruit's crontab.

  33. Contact owners of each image with seeded snaps to have snap channels opened and closed for the new release.

  34. Create new live filesystem configurations for the new distroseries, using branch-livefses in lp:ubuntu-archive-tools. This currently needs to be done for OWNER where OWNER is:

    • ubuntu-cdimage
    • cloudware
    • cloud-images-release-managers

  35. Create data/RELEASE, tools/RELEASE, and tools/boot/RELEASE directories in debian-cd based on corresponding directories for the previous release. Set OFFICIAL to "Alpha" in CONF.sh for the new release.

  36. Adjust cdimage code to be aware of the new release, and configure ~cdimage/.isotracker.conf

  37. Notify stgraber, vorlon, or bdmurray to follow README.series on db@limequat (the ISO tracker database).
  38. Notify Michael Vogt to update the default release in popcon.ubuntu.com and update the component list
  39. Target issues from the previous release's release notes to be fixed in the new release.

  40. Notify Brian Murray or a real ~ubuntu-archive member to create an Apport retracer apt configuration (example for 17.04) for the new release and roll it out to porter-i386:/home/ubuntu-archive/config

  41. Check http://ddebs.ubuntu.com for the new release. (In principle that should happen by itself, but in practice it may crash/hang on archive.ubuntu.com not yet having indexes, or run into time outs on the gigantic first import after opening/copying the new release). This is running on numen.canonical.com → sudo -u ddebs -i; This has a checkout of lp:ddeb-retriever and is cron driven.

  42. Notify Iain Lane or someone with access to the user update config.json to add the new release to the list in git lp:~ubuntu-desktop/+git/appstream-cloud (*make sure the json is valid*), and then as prod-ue-appstream-back@wendigo run juju set appstream-generator config="$(cat config.json)" after pulling. See 9163c1a2bc5fb3c2c2ba1c27df8f7573a54b4045.

  43. Open an RT to ask IS to create chroots on the porter boxes.
  44. Notify William Grant to update the ftbfs on qa.ubuntuwire.com.
  45. Notify Rhonda D'Vine (Rhonda) to update packages.ubuntu.com.
  46. Notify Iain Lane (Laney) to update people.c.c/~ubuntu-archive/transitions and udd.debian.org
  47. Notify Josh Powers (or anybody in ~canonical-server) to update lp:ubuntu-manpage-repository
  48. Notify Brian Murray to update whoopsie-update-daily-users cronjob in the retracer charm owned by the daisy-pluckers team to include the new release of Ubuntu.

  49. Notify Brian Murray to update the Ubuntu Error Tracker for the new release of Ubuntu e.g. errors change and daisy change

  50. Notify someone with access to the "prod-cnf-extractor" group to enable generation of command-not-found indices (juju config cnf-extractor releases="space separated list of releases")

First weeks, after toolchain complete

  1. Notify 'ubuntu-devel' and 'ubuntu-devel-announce' that the release is now open and where to subscribe to the release'-changes' maillist.

  2. Review the people listed in '!regression-alert' (StableReleaseUpdates#Regressions) as needed. '!regression-alert' is handled by ubotto and flagged in #ubuntu-devel. Changes can be made and tested in #ubuntu-ops. The people listed should be the tech leads for foundations, desktop, server, security, and QA, along with the release manager and key community members.

  3. Merge base-files if necessary and change /etc/issue, /etc/issue.net, /etc/lsb-release, and /etc/os-release to refer to the new release.

  4. Merge debootstrap if necessary and create a bootstrap script for the new release as a copy of the previous one (currently, we can just make the new one a symlink to gutsy, as it hasn't changed since then).

  5. Merge lintian, vim, emacs-goodies-el and clang if necessary and update lists of Ubuntu release names to include the new release name.

  6. Do a no change rebuild of devscripts to pick up the new development release from distro-info.
  7. Do a no change rebuild of app-install-data-partner.

  8. Update /usr/share/python-apt/templates/Ubuntu.info in python-apt to include the new release name.

  9. Update ubuntu-release-upgrader to handle the new release e.g. https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/3181 and DistUpgradeQuirks e.g. https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/3232.

  10. Update meta-release to handle the new release e.g. https://bazaar.launchpad.net/~ubuntu-core-dev/meta-release/ubuntu/revision/247.

  11. Update auto-upgrade-testing-specifications so that upgrade testing is done to the new release e.g. https://bazaar.launchpad.net/~canonical-platform-qa/auto-upgrade-testing-specifications/auto-upgrade-testing-specifications/revision/46.

  12. Update syslinux-themes-ubuntu to handle the new release.

  13. Merge cdrom-detect, choose-mirror, and iso-scan if necessary and update cdrom/suite and mirror/suite debconf templates to include a choice for the new release and update any previous default.

  14. Merge the rest of the installer in dependency order, ending with debian-installer once all other installer components have built successfully on all architectures.

  15. Notify ubiquity maintainer(s) to run debian/rules update, adjust as necessary to account for changes, and upload.

  16. Ensure that postgresql-common is updated for new release

  17. Update the version number in unity-greeter & unity-control-center logos to refer to the new release

  18. Ensure that the ISO tracker has a daily-build "milestone" for the new release

  19. Create ~ubuntu-archive/wubi/RELEASE/ and symlink ~ubuntu-archive/wubi/RELEASE-1/stable to ~ubuntu-archive/wubi/RELEASE/stable

  20. Edit default_milestone in ~cdimage/.isotracker.conf to match the new milestone name in the ISO tracker

  21. Notify canonical-platform-qa (qa-team@lists.canonical.com) to set up Utah jobs for Ubuntu desktop and server.

  22. Add new series to production/current-triggers on nusakan.

  23. Turn live filesystem and cdimage cron jobs back on.

  24. Add the date of the previous release to calendar.ubuntu in bsdmainutils

  25. Defect Analysts (or team lead for those teams without Defect Analysts) will triage the +nominations bugs list, declining non-SRU candidate nominations and re-target bugs. The release team will evaluate the remaining list, accepting good SRU candidates

  26. Notify web team to reset http://www.ubuntu.com/testing to indicate no testing in progress, and reference new release.

  27. Check to make sure the future+1 and future+2 series is available on launchpad to assign bugs to, if not present, then ask webops on #launchpad-ops to add letter-series, with status Future.

  28. Update https://wiki.ubuntu.com/ReleaseTeam/FeatureStatus to new release, and all linked pages.

  29. Two weeks after new release starts, finish EndofLifeProcess for any old releases scheduled now that we've had some migration overlap.

  30. Update ubuntu-release-notes project to know about the new series.

  31. Ask firefox maintainer to update start page for the new release.

  32. Contact flavours to confirm their ongoing participation in the new release, and verify that the contact in the ISO tracker is still accurate.

  33. Continue on MilestoneProcess.

CategoryProcess

NewReleaseCycleProcess (last edited 2023-10-20 14:01:26 by tsimonq2)