PointReleaseProcess

Differences between revisions 51 and 52
Revision 51 as of 2012-10-09 17:52:46
Size: 7564
Editor: doko
Comment: mention updating os-release when it exists.
Revision 52 as of 2013-01-25 11:02:11
Size: 7564
Editor: 82-69-40-219
Comment: formatting
Deletions are marked like this. Additions are marked like this.
Line 35: Line 35:
 1  Include the latest translation updates into the sources for the point release.  1. Include the latest translation updates into the sources for the point release.

To be carried out by: nominated stable release manager, with support from the stable release updates and release teams

Goals:

  • Refresh hardware support in LTS releases for carefully-selected hardware
  • Roll up accumulated stable updates into updated images to reduce download requirements for new deployments
  • Maintain stability of existing installations

Between Release minus 6 months and Release minus 2 months:

  1. Discuss candidates for new or improved hardware support with affected parties. Some sources for this work should be:
    • the Canonical support team (via Steve George)
    • customers
    • the Ubuntu kernel team
    • the Ubuntu QA team
  2. Establish a hit-list of bugs to fix in the point release using a milestone. Milestoning bugs is not a commitment to including the changes in the point release; they may be deferred after further information becomes available.
  3. In concert with affected developers, triage the hit-list for feasibility.

Release minus 2 months:

  1. Process stable release updates as normal. For hardware-enabling fixes, the package should be tested on the affected hardware prior to submitting to sign-off for -proposed.

  2. Discuss the possibility of a Canonical press release for the point release with Gerry Carr.
  3. Liaise with IS, QA, community and certification to arrange for testing resources.
  4. Canvas OEM and Support organizations for any bugs important to try to get fixed.

Release minus 1 month:

  1. In coordination with QA, verify that all candidate bugs are fixed.
  2. 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. 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.

  4. Change cdimage/bin/make-web-indices, cdimage/bin/publish-release, and debian-cd/CONF.sh to use the new release version number.

  5. Change cdimage/bin/run-germinate, debian-cd/CONF.sh, and the cdimage crontab to build from -proposed temporarily.

  6. Update the manifest to reflect publishing status of images based on input from product leads.
  7. Build CD images (which will be published on cdimage.ubuntu.com) and smoke-test in some convenient environment to check for obvious failures.
  8. Notify translations-team to prepare updates for point release.

Release minus 3 weeks:

  1. Notify Evan Dandrea to update umenu and wubi for the point release.
  2. Include the latest translation updates into the sources for the point release.
  3. Contact IS, QA, and/or certification as appropriate to request testing for hardware recertification.
  4. Iterate CD images as needed based on testing feedback, in coordination with the kernel team.

Release minus 14 days:

  1. If there is a new debian-installer or new update-manager, then confirm that the Archive Admins have done the necessary by-hand processing from -proposed to -updates, before candidate image builds are started.
  2. Prepare change summary and release announcement

Release minus 7 days:

  1. Once testing is verified to be complete, move packages to -updates.
  2. Turn off cron jobs that will auto update into -updates until final images are tested.
  3. Build candidate release images and populate into iso tracker.
  4. Notify OEM team (irc: KyleN ) to build found license list for main.
  5. 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.

Release minus 3 hours:

  1. Check with James Troup whether the previous point release needs to be moved off before prepublishing due to mirror space constraints.
  2. Pre-publish images: ./publish-image-set --prepublish will print the necessary commands.

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

Release:

  1. Release images as final, and move the previous images to old-releases.ubuntu.com:

    • 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-releases (using a similar procedure to that in EndOfLifeProcess for moving images from cdimage.ubuntu.com to old-images, 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).

    • Archive the old copy of wubi.exe to old-releases, and publish a new one
    • 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.
    • Notify Web team to update the iso URLs on the ubuntu.com website
  2. Create a snapshot of the archive:

    ubuntu-archive@lillypilly:~$ 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.)

  3. Ping mvo to update meta-release file on http://changelogs.ubuntu.com/

  4. File a bug on ubuntu-docs to have https://help.ubuntu.com/community/UbuntuHashes updated.

  5. 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
  6. send the announcement mail (see archives for past examples)
    • ubuntu-announce
    • ubuntu-release
  7. notify press release team (Gerry Carr) - if needed.

Release +1 day:

  1. restore the .manifest.full file on releases.ubuntu.com
  2. deactivate the just released "point release" milestone target
  3. send out update to people running previous LTS (after migration testing completed).
  4. get final summary of updates for release(see lucid-updates.py script), and publish to ???
  5. gather feedback info for future improvements to process


CategoryProcess

PointReleaseProcess (last edited 2022-02-22 09:39:35 by sil2100)