NewReleaseCycleProcess

Revision 146 as of 2014-05-19 14:26:19

Clear message

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 bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/. 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. Notify a webops to run branch-distro to initialize branches for the new series.

  9. Re-enable the Soyuz publisher cron jobs and wait for the first run to complete.
  10. 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).

  11. Verify that the partner repository has been created on archive.canonical.com as a result of this process; if not, notify the Soyuz developers to fix it and check that this happens.

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

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

  14. Move the bootstrap archive on snakefruit to use the new series, so the new chroots can reference it.
  15. 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.
  16. Add a request to Launchpad devs and admins to open Launchpad translations for the new distroseries.

  17. Notify Colin Watson to modify various reports (at least britney) to point to the new distroseries.

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

  19. Notify toolchain developers to upload new toolchain. Iterate uploads as necessary until this has successfully built on all architectures.
  20. Remove the "block-all source" hint from proposed-migration.
  21. Notify a Launchpad admin to set the status of the new distroseries to DEVELOPMENT.

  22. Check with a webops that branch-distro has completed.

  23. Notify #launchpad-ops (or someone with access to jubany) to add the new series name in the lp:udd code, pull that change onto the package importer, and restart package-import.
  24. Inform #ubuntu-devel and ubuntu-devel-announce that the new release is now open for uploads, pointing to merge-o-matic output.

  25. Check whether there are any uploads in the previous release's -updates pocket not in the new release, and copy them over if so.
  26. Uncomment the auto-sync job in ubuntu-archive@snakefruit's crontab.

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

  28. Ask WebOps to bootstrap the build-RELEASE-live chroot on the buildds for the livefs builds

  29. Update UbuntuDevelopment, ArchiveAdministration to reflect the code name of the current release

  30. Notify Michael Vogt to update the default release in popcon.ubuntu.com and update the component list
  31. Target issues from the previous release's release notes to be fixed in the new release.
  32. Notify Michael Vogt or Serge Hallyn to update vm-builder so that it can build VMs for the new release
  33. Ask an ~app-review-board member to copy a package from release to release+1, wait for the publisher to run, then remove the package. This creates the required entries under dists/ which will be mirrored within 24h to extras.ubuntu.com.
  34. Notify Martin Pitt or Sebastian Bacher to create an Apport retracer apt configuration for the new release.
  35. Notify Martin Pitt to set up http://ddebs.ubuntu.com for the new release.

  36. Notify Chris Johnston to disable previous releases work item tracker reports.
  37. Open an RT to ask IS to create chroots on the porter boxes.
  38. Notify William Grant to update the ftbfs on qa.ubuntuwire.com.
  39. Notify Evan Broder to update lintian.ubuntuwire.com.
  40. Notify Gerfried Fuchs (Rhonda) to update packages.ubuntu.com.
  41. Notify Iain Lane (Laney) to update people.c.c/~ubuntu-archive/transitions
  42. Notify Dimitri Ledkov / Dustin Kirkland (or anybody with ~ubuntu-core-dev) to update lp:ubuntu-manpage-repository
  43. Notify Jean-Baptiste Lallement (jibel) or Martin Pitt (pitti) to initialize autopkgtest for the new release and carry over history from previous series to detect regressions.

  44. Notify Jean-Baptiste Lallement (jibel) or Martin Pitt (pitti) to initialize autopkgtest in the ubuntu-mozilla-security and firefox-next PPAs for the new release.

  45. Notify Brian Murray to update whoopsie-update-daily-users cronjob in canonical-is-puppet to include the new release of Ubuntu.
  46. Notify MPT to select new color for errors.ubuntu.com.
  47. Notify Brian Murray to update errors.ubuntu.com to display the new release of Ubuntu.

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. Update /usr/share/python-apt/templates/Ubuntu.info in python-apt to include the new release name.

  8. Update meta-release, ubuntu-release-upgrader, and syslinux-themes-ubuntu to handle the new release.

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

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

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

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

  13. Ensure that the ISO tracker has a daily-build "milestone" for the new release
  14. Create ~ubuntu-archive/wubi/RELEASE/ and symlink ~ubuntu-archive/wubi/RELEASE-1/stable to ~ubuntu-archive/wubi/RELEASE/stable

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

  16. Turn live filesystem and cdimage cron jobs back on.
  17. Add the date of the previous release to calendar.ubuntu in bsdmainutils

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

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

  20. 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.
  21. Update https://wiki.ubuntu.com/ReleaseTeam/FeatureStatus to new release, and all linked pages.

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

  23. Update ubuntu-release-notes project to know about the new series.
  24. Ask firefox maintainer to update start page for the new release.

  25. Continue on MilestoneProcess.


CategoryProcess