Focal Fossa (20.04.2 LTS) Point-Release Status Tracking

Project Discussion Release
2

Release checklist

The following list is strictly for ubuntu-release team members, based on the PointReleaseProcess document.

Legend:

  • :soon: - Task assigned and worked on
  • :heavy_check_mark: - Task finished
  • :heavy_multiplication_x: - Task skipped or failed
  • XXX - Task contents added or modified during this release

Release minus 6 weeks:

  1. :heavy_check_mark: Create a release tracking Discourse thread for the release in mention. This should include:
    • On top, a short summary of the current state of the release
    • Sections for release blocker and upgrade blocker bugs
    • Section for bugs to watch for
    • Copy of the release checklist as actual checklist items
  2. :heavy_check_mark: Coordinate with the kernel team to ensure HWE kernels are updated to the new target release (Kernel/RollingLTSEnablementStack#Update_Schedule-2).

Release minus 1 month:

  1. :heavy_check_mark: In coordination with QA, verify that all candidate bugs are fixed.
  2. :heavy_multiplication_x:If the kernel or associated modules have been changed, upload debian-installer after all the binaries are in place. If the ABI changed, make sure to take account of this throughout debian-installer/build/config/ and in the installer seed for all flavours being built.
    • Before pushing the debian-installer packages to the archive, do a test build in a PPA to make sure no size bumps are needed.
    • This step is no longer needed for series focal and newer as debian-installer is no longer used in any installation media.
  3. :heavy_check_mark: If this point release includes the switch to enable the HWE stack (usually XX.XX.2):
    • Make sure that the variant list in livecd-rootfs’s live-build/ubuntu-server/hooks/033-kernel-bits.binary hook includes both ga and hwe to make sure subiquity offers both kernel flavors. Upload and fast-forward into -updates in case it doesn’t.
    • Make sure that the server-ship-live seed includes the new hwe kernel.
    • Check and mark livecd-rootfs auto/config LB_KERNEL_FLAVOURS to the -hwe-XX.XX variant for every desktop flavor participating.
  4. :heavy_check_mark: Change cdimage/lib/cdimage/config.py and debian-cd/CONF.sh to use the new release version number.
  5. :heavy_check_mark: Make sure that that we are building the daily images with -proposed enabled.
  6. :heavy_check_mark: Update the manifest to reflect publishing status of images based on input from product leads.
  7. :heavy_check_mark: Build CD images (which will be published on cdimage.ubuntu.com) and smoke-test in some convenient environment to check for obvious failures.
  8. :heavy_check_mark: Notify translations-team to prepare updates for point release.

Release minus 3 weeks:

  1. :heavy_check_mark: Include the latest translation updates into the sources for the point release.
  2. :heavy_check_mark: Contact IS, QA, and/or certification as appropriate to request testing for hardware recertification.
  3. :heavy_check_mark: Iterate CD images as needed based on testing feedback, in coordination with the kernel team.
  4. :heavy_check_mark: Check to see if python-apt has been uploaded recently. If not, upload a new version.
  5. :heavy_check_mark: Check to see if ubuntu-release-upgrader have been uploaded recently. If not, upload a new version after running pre-build.sh as that generates the updated lists of mirrors.
  6. :heavy_check_mark: Ensure that the stable/ubuntu-XX.YY.Z branch has been published for the subiquity snap.

Release minus 14 days:

  1. :heavy_check_mark: Prepare change summary and release announcement
    • Script to use for preparing the change summary: http://people.canonical.com/~vorlon/release-updates.py
    • Sort and/or re-divide updates into rough categories (see previous summaries)
    • Remove administrative-only bugs (e.g. kernel release tracking)
    • Try to reduce each entry to just a description of the change; remove redundant bug references and information about where the change came from (people can go to the raw changelog if they care)
    • This can involve substantial amounts of editing; make sure you have a good editor and/or a clear grasp of regular expressions
    • If this point release includes an HWE stack, communicate the life cycle of this HWE stack
    • If this is the final point release for the distroseries (because a new LTS will be released soon), include a reminder of this and of the support cycle/EOL

Release minus 7 days:

  1. :heavy_check_mark: Notify web team of the upcoming point release.
    • Determine who from the team the publishing contact will be.
    • Include summary list of actual file names of ISOs that will make up releases.
    • Include detailed information about which image file names will change on the mirrors for the point release, and which ones will not.
    • Discuss release stability and handoffs on release date.
  2. :heavy_check_mark: Upload a new base-files package to -proposed to bump the lsb_release description (example for 8.04.4). Do not change the DISTRIB_RELEASE value, which is used programmatically by third-party software. If the etc/os-release file exists, update VERSION and PRETTY_NAME, don’t update VERSION_ID.
  3. :heavy_check_mark: Push base-files through to -updates.
  4. :heavy_check_mark: Once testing is verified to be complete, move packages to -updates. This should vary depending on how much testing of the daily -proposed images has been done - ideally we want to flush the whole -proposed pocket to not invalidate the earlier testing.
    • Make sure debian-installer has picked up all the installer related changes and doesn’t require a re-build.
  5. :heavy_check_mark: Analyze the package diffs between last point-release and the current daily image for each participating flavour (stripping versions) to make sure no changes are pulling in a bunch of new/unexplained packages.
  6. :heavy_multiplication_x: : Turn off cron jobs that will auto update into -updates until final images are tested.
  7. :heavy_check_mark: Build candidate release images and populate into iso tracker. Make sure that those images are NOT building with -proposed enabled. Re-spin when appropriate.
    • Before running builds, make sure cdimage is up-to-date with archive contents and run anonftpsync on nusakan.
    • Also remember about building source images along with those (e.g. DIST=xenial cron.source), re-spinning when appropriate.
    • Remember about building core images as well (as per UbuntuCore/ReleaseProcess).
  8. :heavy_check_mark: Create a snapshot of the archive: ubuntu-archive@snakefruit:~$ point-release-snapshot lucid lucid.3-security-updates-snapshot which will copy the relevant indices to a subdirectory of ~ubuntu-archive/point-releases/. (Packages may be retrieved from the Launchpad librarian if required.)
    • Remember to re-create the snapshot whenever new candidate images are built.
  9. :heavy_multiplication_x: Notify OEM team (irc: KyleN) to build found license list for main.

Release minus 3 hours:

  1. :heavy_check_mark: Check with James Troup whether the previous point release needs to be moved off before prepublishing due to mirror space constraints.
  2. :heavy_multiplication_x: If this point-release is an LTS with an OEM stack, contact the Certification Team for a formal sign off of the images.
  3. :heavy_check_mark: Pre-publish images: ./publish-image-set --prepublish will print the necessary commands.
  4. :heavy_check_mark: Copy .manifest to .manifest.full, and prune all images from previous releases from the .manifest file to allow timely mirror probing.
  5. :heavy_check_mark: Run sync-mirrors on nusakan to push out the pre-published file structure.

Release:

  1. :heavy_check_mark: Release images as final, and move the previous images to old-releases.ubuntu.com:
    • Archive the old copy of wubi.exe to old-releases, and publish a new one (do this first so that its timestamp will be newer than that of the checksum files so that the checksums will be updated properly)
    • Find which previous images on cdimage.ubuntu.com for this release are going to be replaced by this image set, and archive them to old-images (using a similar procedure to that in EndOfLifeProcess for moving images from cdimage.ubuntu.com, but leave /srv/cdimage.ubuntu.com/www/full/netboot/RELEASE/ alone).
    • Publish images: ./publish-image-set.py will print the necessary commands.
    • Update version numbers in cdimage/www/simple/HEADER.html and cdimage/www/simple/.htaccess.
    • Archive releases.ubuntu.com images from the previous point release to old-releases (using a similar procedure to that in EndOfLifeProcess, but being more selective about which files to move).
    • Copy .manifest to .manifest.full again, pruning all images from previous releases from the .manifest file to allow timely mirror probing.
    • Run sync-mirrors on nusakan to push out the published file structure.
      • If you moved images to old-releases, remember to run sync-old-releases as well.
    • Notify Web team to update the iso URLs on the ubuntu.com website
    • Remember to publish core images as well (as per UbuntuCore/ReleaseProcess).
  2. :heavy_check_mark: Ping bdmurray to update meta-release file on http://changelogs.ubuntu.com/
  3. :heavy_check_mark: Regenerate the Raspi Installer JSON file to include the latest images and checksums (ping waveform or sil2100).
  4. :heavy_check_mark: Work with release and web publishing team to monitor mirror pickup
    • verify download from ubuntu.com
    • check that the torrents are working
    • verify download from one of the mirrors
  5. :heavy_check_mark: Send the announcement mail (see archives for past examples)
    • ubuntu-announce
    • ubuntu-release
    • Post on Discourse
  6. :heavy_multiplication_x: Notify press release team if needed

Release +1 day:

  1. :heavy_check_mark: Restore the .manifest.full file on releases.ubuntu.com
  2. :heavy_check_mark: Deactivate the just released “point release” milestone target
  3. :heavy_check_mark: Re-enable -proposed for daily builds on cdimage
  4. :heavy_check_mark: Re-enable daily builds
  5. :heavy_multiplication_x: Send out update to people running previous LTS (after migration testing completed).
  6. :heavy_multiplication_x: Get final summary of updates for release (see precise-updates.py script), and publish to ???
  7. :soon: Gather feedback info for future improvements to process
2 Likes