Bionic Beaver (18.04.6 LTS) Extra Point-Release Status Tracking

Release
1

This page is the canonical tracking document for the extra Bionic Beaver point-release (18.04.6). It’s a live document. The Ubuntu release team will be updating it as we work on releasing 18.04.6.

Status

  • Released!

Summary

  • This is an extra bionic point-release to refresh the images after the recent key revocations.

Current blockers

  • None

Bugs to watch

  • snapd to be released after .6.

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_multiplication_x: Coordinate with the kernel team to ensure HWE kernels are updated to the new target release (Kernel/RollingLTSEnablementStack#Update_Schedule-2).
    • We’re releasing with what we have here.

Release minus 1 month:

  1. :heavy_multiplication_x: In coordination with QA, verify that all candidate bugs are fixed.
  2. :heavy_check_mark: 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_multiplication_x: 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. 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_multiplication_x: Notify translations-team to prepare updates for point release.
    • Same here: we’re not building new langpacks and releasing with what we have

Release minus 3 weeks:

  1. :heavy_multiplication_x: 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.
    • Make sure to get early feedback on certification testing from the daily images.
  3. :heavy_check_mark: Check to see if python-apt has been uploaded recently. If not, upload a new version.
  4. :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.
  5. :heavy_check_mark: Ensure that the stable/ubuntu-XX.YY.Z branch has been published for the subiquity snap.

Release minus 14 days:

  1. :soon: 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
  2. :heavy_check_mark: Make sure all critical package updates are by now done and landed in -updates or -security.
  3. :heavy_check_mark: Disable -proposed for the series daily image builds (to build images as close to the final product as possible).
  4. :heavy_multiplication_x: Ask Certification and QA to start performing preliminary image testing on the daily images as much as possible from now till release, identifying any release critical bugs that have not been noticed earlier.
  5. :heavy_check_mark: Coordinate with the SRU team to be more careful on which packages get promoted to -updates, keeping the incoming point-release in mind.
    • Keep in mind that due to the fact that even release-critical bugs require an aging and verification period as per the usual SRU policy, this is the final ‘safe’ moment whenever release facing updates can be accepted without risking the delay of the point release.

Release minus 7 days:

  1. :heavy_multiplication_x: 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: Send out an e-mail notifying developers of the -updates pocket freeze for the duration of the point-release.
  8. :heavy_check_mark: Build candidate release images and populate into iso tracker (double check 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 ancientminister.
    • Also remember about building source images along with those (e.g. DIST=focal cron.source), re-spinning when appropriate.
    • Remember about building core images as well (as per UbuntuCore/ReleaseProcess).
  9. :heavy_check_mark: Create a snapshot of the archive: ubuntu-archive@snakefruit:~$ point-release-snapshot focal focal.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.

Release minus 3 hours:

  1. :heavy_multiplication_x: Check with IS 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 ancientminister 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:
    • :heavy_check_mark: 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).
    • :heavy_check_mark: Publish images: ./publish-image-set.py will print the necessary commands.
    • :heavy_check_mark: Update version numbers in cdimage/www/simple/HEADER.html and cdimage/www/simple/.htaccess.
    • :heavy_check_mark: 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).
      • :heavy_check_mark: Update entries in cdimage/www/old-releases/HEADER.html and cdimage/www/old-releases/.htaccess.
      • :heavy_check_mark: Edit cdimage/www/simple/.htaccess to add RedirectPermanent entries for the previous point release, and remove the corresponding symlinks from cdimage/www/simple.
    • :heavy_check_mark: Copy .manifest to .manifest.full again, pruning all images from previous releases from the .manifest file to allow timely mirror probing.
    • :heavy_check_mark: Run sync-mirrors on ancientminister to push out the published file structure.
      • :heavy_check_mark: If you moved images to old-releases, remember to run sync-old-releases as well.
    • :heavy_multiplication_x: Notify Web team to update the iso URLs on the ubuntu.com website
    • :soon: 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_multiplication_x: 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
    • Update Discourse Tracking bug
  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_multiplication_x: Re-enable -proposed for daily builds on cdimage
  4. :heavy_multiplication_x: Re-enable daily builds
  5. :heavy_multiplication_x: Send out update to people running previous LTS (after migration testing completed).
  6. :heavy_multiplication_x: Gather feedback info for future improvements to process