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

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. If there is a release scheduled to End of Life, start off EndOfLifeProcess for it.

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

    • Update ReleaseSchedule

    • Ask teams to add major transitions/changes to the release schedule.

    • Add events for key release dates to the Canonical Ubuntu Release Calendar and invite ab54tjqqlaol3rdnksieju8mcc@group.calendar.google.com (Ubuntu News Release Calendar) to the events. When you invite them choose “Guests can modify event” and do not “send invitations to new guests”. N.B. Don't forget the EoL date!

      • Additionally create an event 45 days before the EoL date to remind the release team to send the "Ubuntu XX.YY EoL Reminder" - do not invite the Ubuntu News Release Calendar to this event.

Previous release minus 2 weeks

  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.

  2. Create a release schedule for the new series. If the release name is not yet known, substitute the letter twice, e.g. FF for the F-series.
  3. Create a release notes document for the new series. If the release name is not yet known, substitute the letter twice, e.g. FF for the F-series.
  4. Close the new threads, so they can be edited but not replied to. Release team members can do this. Until Discourse can sync groups from SSO (LP) directly, the release team group in Discourse is manually managed. Contact an admin (e.g. the Canonical community team) to be added if you need this.

Previous release plus 1 day

  1. Edit (cowboy) run-proposed-migration on snakefruit to disable proposed-migration for the new series (add an exit 0 to the ubuntu/$DEFAULT_SERIES case branch). proposed-migration must not run until autopkgtest is ready to receive test requests for the series.

  2. Update lp:ubuntu-archive-scripts update-seeds, update-germinate etc. for the new name and pull it into snakefruit:~ubuntu-archive/bin/. This will cause update-seeds to start failing until the below step is done, so do it quickly afterwards.

  3. 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.

  4. Create new seed branches based on those for the previous release, and push them to the appropriate branches on Launchpad. The branch-seeds script in lp:ubuntu-archive-tools can do the hard work here:
    1. Have a checkout of all the seeds for the current stable release as COLLECTION.series

    2. Run branch-seeds --dest-series <new series> <collection> ... for all the collections

    3. Run update-seeds manually on snakefruit to confirm this all worked. Check the exit status is 0.
  5. Request Launchpad disable the primary Ubuntu publisher cron jobs:

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

    • Copy the Release Manager and Drivers forward
  7. Create milestones in the new series:
    • ubuntu-YY.MM etc., set at monthly intervals after the previous release until feature freeze
    • ubuntu-$version-feature-freeze, ubuntu-$version-beta or ubuntu-$version-beta-1 etc. as required
    • ubuntu-$version at the next release date
    • ubuntu-$version-updates at EOL

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

  9. 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. Wait for this to finish before running the publisher, this will take 15 to 30 minutes.

    • In the event that a new architecture was added ensure it is also added to command-not-found-extractor's update_all.sh script.

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

  11. 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.

  12. After the first publisher run has completed, ask ~IS to run "ANALYZE sourcepackagepublishinghistory; ANALYZE binarypackagepublishinghistory;" on launchpad_prod.
  13. Re-enable the Soyuz publisher cron job for a second publisher run. Watch the logs to make sure this work.

  14. 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).

  15. Permanently re-enable the Soyuz publisher cron job
  16. Copy the pending syncs which we didn’t want to accept from previous-proposed UNAPPROVED, and then reject them

  17. Notify juliank, sil2100, or vorlon to run through https://autopkgtest-cloud.readthedocs.io/en/latest/administration.html#opening-up-a-new-series

  18. Update lp:~ubuntu-release/britney/britney1-ubuntu/ with the new DEFAULT_SERIES.
  19. Once autopkgtest is ready:

    • on snakefruit, cp -a ~/proposed-migration/data/OLDRELEASE ~/proposed-migration/data/NEWRELEASE and cp -a ~/proposed-migration/data/OLDRELEASE-proposed ~/proposed-migration/data/NEWRELEASE-proposed so that we do not reset state for devel.

    • undo the run-proposed-migration cowboy from above, so that proposed-migration can start running for the new series.
  20. XXX: partner is being deprecated, check with Steve Langasek if you find there are any packages to copy.

    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).

  21. [~techboard] 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).

  22. Move the bootstrap archive on snakefruit to use the new series, so the chroots can reference it.

  23. As prod-launchpad's launchpad@launchpad-ftpmaster-uploader/leader, run LPCONFIG=launchpad-ftpmaster-uploader /srv/launchpad/code/scripts/add-missing-builds.py -s NEW-proposed plus -a ARCH for each architecture in NEW (ask IS).

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

    • Also make sure this actually happens. (TODO: Work out a better process for keeping track of this in conjunction with Launchpad.)

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

    • britney: ~ubuntu-archive/public_html/proposed-migration: Update symlinks
    • See the bzr log in ~ubuntu-archive/ubuntu-archive-tools for the changes done for the last release and update to the current one.
    • Add the new release to ~ubuntu-archive/.madison-lite/config on snakefruit so that rmadison starts working.

  26. Notify someone in the 'merges' LDAP group to set up merge-o-matic to point to the new distroseries. Switch to the merge user, cd /srv/patches.ubuntu.com/code/, bzr pull.

  27. Upload some basic packages for the new series.
    • Update distro-info-data for the new series.
    • 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.
    • Add the symlink for the new series in debootstrap [No longer needed, check if we need to SRU this -tsimonq2]
    • Make sure these are migrated and ping the cpc team to do the livefs builds.

  28. Update global.conf and go in lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs

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

    1. Check that https://people.canonical.com/~ubuntu-archive/proposed-migration/<NEWSERIES>/autopkgtest-results.cache exists, as required by bileto. If not, this can be done by creating a new symlink to the proposed-migration’s data directory.

  31. Remove the "block-all source" hint from proposed-migration.
  32. Once the tool chain is ready:

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

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

  33. Check whether there are any uploads in the previous release's -updates pocket not in the new release, and copy them over if so.
  34. [~ubuntu-archive] Copy everything from PREVIOUS-proposed to DEVEL-proposed, and delete the ones from PREVIOUS-proposed that aren't SRUs.

  35. [~techboard] 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).

  36. 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.

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

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

  39. Create new live filesystem configurations for the new distroseries, using branch-livefses in lp:ubuntu-archive-tools. This requires someone in ~launchpad-ppa-admins/~launchpad-ppa-self-admins, ~ubuntu-cdimage and ~launchpad-livefs-builders. This currently needs to be done for OWNER where OWNER is:

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

  40. 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.

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

  42. Notify stgraber, vorlon, or bdmurray to follow README.series on db@limequat (the ISO tracker database) after sudo'ing to db. Then confirm that the new series has a manifest in the ISO tracker administrative interface.
  43. Target issues from the previous release's release notes to be fixed in the new release.

  44. 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. Additionally, enable -proposed for the version of Ubuntu which was just released. It'd also be good to clean out the retracer cache (in /home/ubuntu-archive/cache-$arch/) for the previous development release as crashes should no longer be submitted to Launchpad.

  45. 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 ddebs.internal → sudo -u ddebs -i; This has a checkout of lp:ddeb-retriever and is cron driven.

  46. 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.

  47. Notify William Grant to update the ftbfs on qa.ubuntuwire.com.
  48. Notify Rhonda D'Vine (Rhonda) to update packages.ubuntu.com.
  49. Notify Iain Lane (Laney) to update people.c.c/~ubuntu-archive/transitions and udd.debian.org

  50. Update lp:ubuntu-manpage-repository for the new release codename e.g. adding a release, and submit an RT to have the server updated.

  51. 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.

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

  53. 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")

  54. 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.

  55. If the new release is an LTS, reach out to the official Ubuntu flavors regarding their LTS status (the maintenance period) and, after gathering feedback, updating both the release schedule and release notes discourse threads.

  56. Revisit the post-release items for the release which was just performed, confirm they were completed, and complete them now if not.

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. Notify the Launchpad team to upload new buildd chroots (which should be done occasionally throughout the cycle, for efficiency).

  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. In the past, we had to symlink each release to gutsy, now it is read from distro-info-data automatically. Check if this needs to be SRUed.

  5. Merge lintian if necessary and update the lists of Ubuntu release names to include the new release name in all supported releases of Ubuntu (i.e. SRU it!).

  6. Merge vim if necessary and update lists of Ubuntu release names to include the new release name.

  7. Merge clang if necessary and update lists of Ubuntu release names to include the new release name.

  8. Do a no change rebuild of devscripts to pick up the new development release from distro-info.

  9. Update meta-release-development to handle the new release.

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

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

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

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

  14. If needed (if anything is not open ended in the second column) new series to production/current-triggers on cdimage-builder.internal.

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

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

  17. 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

  18. 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.

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

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

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

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

  23. Have Debian update the udd config for the new Ubuntu development release codename

  24. If it has not already been done calculate the release date for the next release of Ubuntu. In general, October releases follow a 25-week schedule, while April releases follow a 27-week schedule, to compensate for year-end holiday (non-LTS releases might break this cycle to wiggle things a bit). Add the release date to the Canonical Ubuntu Release Calendar.

  25. Continue on MilestoneProcess.

CategoryProcess

NewReleaseCycleProcess (last edited 2024-05-09 04:29:15 by wgrant)