PointReleaseProcess
7418
Comment: publish found license list.
|
7518
|
Deletions are marked like this. | Additions are marked like this. |
Line 60: | Line 60: |
1. Run `sync-mirrors` on antimony to push out the pre-published file structure. | 1. Run `sync-mirrors` on nusakan to push out the pre-published file structure. |
Line 70: | Line 70: |
* Run sync-mirrors on antimony to push out the published file structure. | * Run sync-mirrors on nusakan to push out the published file structure. |
Line 75: | Line 75: |
{{{lp_archive@cocoplum:~$ point-release-snapshot lucid lucid.3-security-updates-snapshot}}} | {{{ubuntu-archive@lillypilly:~$ point-release-snapshot lucid lucid.3-security-updates-snapshot}}} |
Line 77: | Line 77: |
which will create a hardlink farm in `~lp_archive/point-releases/`. | which will copy the relevant indices to a subdirectory of `~ubuntu-archive/point-releases/`. (Packages may be retrieved from the Launchpad librarian if required.) |
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:
- 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
- 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.
- In concert with affected developers, triage the hit-list for feasibility.
Release minus 2 months:
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.
- Discuss the possibility of a Canonical press release for the point release with Gerry Carr.
- Liaise with IS, QA, community and certification to arrange for testing resources.
- Canvas OEM and Support organizations for any bugs important to try to get fixed.
Release minus 1 month:
- In coordination with QA, verify that all candidate bugs are fixed.
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 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.
Change cdimage/bin/make-web-indices, cdimage/bin/publish-release, and debian-cd/CONF.sh to use the new release version number.
Change cdimage/bin/run-germinate, debian-cd/CONF.sh, and the cdimage crontab to build from -proposed temporarily.
- Update the manifest to reflect publishing status of images based on input from product leads.
- Build CD images (which will be published on cdimage.ubuntu.com) and smoke-test in some convenient environment to check for obvious failures.
- Notify translations-team to prepare updates for point release.
Release minus 3 weeks:
- Notify Evan Dandrea to update umenu and wubi for the point release. 1 Include the latest translation updates into the sources for the point release.
- Contact IS, QA, and/or certification as appropriate to request testing for hardware recertification.
- Iterate CD images as needed based on testing feedback, in coordination with the kernel team.
Release minus 14 days:
- 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.
- Prepare change summary and release announcement
script to use for preparing the change summary: http://people.canonical.com/~cjwatson/lucid-updates.py
- 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:
- Once testing is verified to be complete, move packages to -updates.
- Turn off cron jobs that will auto update into -updates until final images are tested.
- Build candidate release images and populate into iso tracker.
- Notify OEM team (irc: KyleN ) to build found license list for main.
- 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:
- Check with James Troup whether the previous point release needs to be moved off before prepublishing due to mirror space constraints.
Pre-publish images: ./publish-image-set.py --prepublish will print the necessary commands.
- Copy .manifest to .manifest.full, and prune all images from previous releases from the .manifest file to allow timely mirror probing.
Run sync-mirrors on nusakan to push out the pre-published file structure.
Release:
Release images as final, and move the previous images to old-releases.ubuntu.com:
Find which images from previous point releases on cdimage.ubuntu.com 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 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, cdimage/www/simple/kubuntu/HEADER.html, cdimage/www/simple/.htaccess, and cdimage/www/simple/kubuntu/.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
- 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.)
Ping mvo to update meta-release file on http://changelogs.ubuntu.com/
File a bug on ubuntu-docs to have https://help.ubuntu.com/community/UbuntuHashes updated.
- work with release and web publishing team to monitor mirror pickup
- verify download from ubuntu.com
- verify download from one of the mirrors
- send the announcement mail (see archives for past examples)
- ubuntu-announce
- ubuntu-release
- notify press release team (Gerry Carr) - if needed.
Release +1 day:
- restore the .manifest.full file on releases.ubuntu.com
- deactivate the just released "point release" milestone target
- send out update to people running previous LTS (after migration testing completed).
- get final summary of updates for release(see lucid-updates.py script), and publish to ???
- gather feedback info for future improvements to process
PointReleaseProcess (last edited 2022-02-22 09:39:35 by sil2100)