ReleaseProcess

Revision 123 as of 2019-10-15 10:34:36

Clear message

To be carried out by the Ubuntu release team

Goals:

  • Ship it!

After final Beta Release is published:

  1. Work with universe/multiverse community to identify delegates to approve Feature Freeze Exceptions, in addition to ubuntu-release until the date of Final Freeze for universe.
  2. Set the Final Freeze date (typically at release day minus 1.5 days) for universe/multiverse for the packages that are NOT found on any installation media.

  3. Universe/multiverse delegates and final freeze date is broadcast to ubuntu-devel-discuss and ubuntu-devel-announce.
  4. Check the minimum memory, disk requirements for installation and:
    1. update https://help.ubuntu.com/community/Installation/SystemRequirements

    2. update bin/make-web-indices

Release minus 14 days:

  1. NonLanguagePackTranslationDeadline, ensure uploads with updated translations downloaded from Rosetta are done for:

    1. ubiquity (debian-installer)
    2. ubiquity-slideshow-ubuntu
    3. gfxboot-theme-ubuntu
    4. yelp, gnome-user-docs and ubuntu-docs
    5. DDTP data (package description translations)
  2. Notify Language Translation Lead (GunnarHj) and the current langpack-o-matic maintainer (sil2100) to coordinate a fresh set of language packs which will be exported, uploaded, and built in time for the release.

  3. If the new release is an LTS, make sure that hwe-support-status (located in update-manager) is up to date with the current HWE stack info, dates and versions.

Release minus 10 days:

  1. If any image names have changed since the previous cycle, notify the web team (#web-team on canonical; email: webteam@canonical.com) to check the website downloader code. Ask the web team to review Release Manifest.

  2. Start off release notes and announce framework. Call for ubuntu-docs and other team participation in content creation of overview and documentation of release bugs.

Release minus 7 days (release candidate week):

  1. Selectively accept package uploads to resolve targeted bugs
  2. Go through ReleaseChecklist (again, yes)

  3. Review list of full iso image names and plans with web team (#web-team on canonical; email: webteam@canonical.com)

  4. Review full iso image sizing with cross check for mirror space issues with IS (Jonathan Davies)
  5. Disable apport and kerneloops uploads to Launchpad ('problem_types': ['Bug', 'Package'], in /etc/apport/crashdb.conf)

  6. Notify Ubuntu, Kubuntu and other flavour contacts to create and update their Upgrade docs at https://help.ubuntu.com/community/RaringUpgrades

Release minus 6 days:

  1. Contact the web team to confirm that:
  2. Post full set of pre-release images with last language pack updates to QA iso tracker to start QA testing.
  3. Turn off daily builds (unless explicit reason why they need to remain on).

Release minus 3 days:

  1. Make sure that /etc/issue, /etc/issue.net, /etc/lsb-release, and /etc/os-release are correct

  2. Modify debian-cd/CONF.sh to set OFFICIAL

  3. Ensure that the ISO tracker lists the new milestone with the "publish from manifest" flag set.
  4. Produce a full set of official images
  5. Clear out the testing grid
  6. Clear the NBS list.

  7. Notify Hardware Certification team ( email: hardware-certification@canonical.com ) to begin CertificationTestingProcess (private due to agreements with vendors)

  8. Notify QA to begin ReleaseValidationProcess

  9. Prepare the release announcement
    • Notify Flavor Product Managers (Kubuntu, Xubuntu, Lubuntu, Ubuntu Studio, Ubuntu MATE, Ubuntu Budgie, Ubuntu Kylin) to prepare separate release announcements and review/update Release Notes.
    • this should refer to the web page prepared by the teams rather than going into details of changes itself
    • update the page to include any caveats
  10. Review targeted bugs and take final decisions on what to fix and what to defer
  11. Apply a "block-all source" hint to proposed-migration; any further changes to -proposed not intended for SRU will need to be unblocked manually

Release minus 1 day:

  1. Pre-publish the CD images: ./publish-image-set --prepublish will print the necessary commands.

  2. Copy .manifest to .manifest.full, and prune all images from previous releases from the .manifest file to allow timely mirror probing
  3. Run sync-mirrors on nusakan to push out the pre-published file structure.

  4. Begin running the mirror prober hourly on staging.ubuntu.com to monitor the propagation of the images to mirrors
  5. Review on the staging server the feature walk through on the website (web-team)
  6. Build the sources images (cron.source) to be published, by the publisher script.

Release minus 6 hours:

  1. If there is a previous milestone for this series, move those images from /srv/cdimage.ubuntu.com/www/full to /srv/cdimage.ubuntu.com/old-images/, and notify the sysadmin team that these are available for off-line archival.
  2. Publish the CD images: ./publish-image-set will print the necessary commands.

    • You need to edit cdimage/www/simple/HEADER.html and cdimage/www/simple/.htaccess by hand to drop the mention of "Release Candidate", since neither publish-release nor publish-image-set is yet smart enough to do the right thing there.

  3. Copy .manifest to .manifest.full again, pruning all images from previous releases from the .manifest file to allow timely mirror probing
  4. Run sync-mirrors on nusakan to push out the published file structure.

  5. Update the Cloud images (IRC: fginther or rcj) - see checklist on https://wiki.ubuntu.com/UbuntuCloud/Images/Publishing

    • log into nectarine and start screen.
    • run ~vmbuilder/bin/vbcron promote-daily release --make-public -release... /srv/ec2-images/server/maverick/20101007.1 --verbose
    • log into amazon server and update the ami pages
  6. Run the mirror prober continuously to verify which mirrors are up to date; output visible here

  7. Check torrents for proper functionality.
  8. Confirm that website content is finalized, as further edits will be difficult under load and check with sysadmin that caches will be cleared on time (web-team, IS, release-team).

Release minus 1 hour:

  1. Coordinate with web team for publishing of staging.
  2. Coordinate with PR team (Sian Aherne) to inform media who are waiting for launch to post their articles.

Release:

  1. Update the topic on #ubuntu-devel, #canonical, and #ubuntu-release-party and make announcement in #ubuntu-release-announce, and then in #ubuntu-release-party.

  2. Update the meta-release index (BrianMurray updates the bzr branch and update the meta-release* bzr branch (as user changelogs) on rubay /srv/changelogs.ubuntu.com/meta-release and copies updated files to /srv/changelogs.ubuntu.com/www)

  3. Switch the development release from its codename to its version in errors/templates/bucket.html in errors

  4. Notify web team to announce on the website
    • News sidebar
    • Box at top of home page
  5. Send the release announcement to ubuntu-announce.

  6. Notify a Launchpad admin to set the status of this distrorelease to CURRENT, and to change any previous CURRENT distrorelease(s) to SUPPORTED.

  7. Deactivate release milestone in Launchpad.
  8. Post announcement to News & Announcements section (forum admins have posting rights)

  9. Post announcement to Launchpad (ubuntu-drivers members have posting rights)

  10. Branch lp:~ubuntu-release/britney/hints-ubuntu/ to lp:~ubuntu-sru/britney/hints-ubuntu-<thisrelease> (To ensure it's available before any 0-day SRUs are uploaded)

  11. Sleep!

Release plus 1 day:

  1. If any changes were made to this document in this run, check whether the changes also apply to AlphaProcess, BetaProcess or ReleaseCandidateProcess.

  2. Continue on NewReleaseCycleProcess.

  3. Update Relevant community documentation with references to this new release

    1 Review through the process pages, and update to the release name (e.g. oneiric->precise)

Release plus ~ 2 weeks:

  1. Hold PostReleaseReview session at UDS, and feed input into updating processes, and next release cycle.


CategoryProcess