PointReleaseProcess
2187
Comment: initial incomplete draft
|
5188
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
''This is an incomplete DRAFT.'' To be carried out by: nominated stable release manager, with support from the [https://launchpad.net/~ubuntu-sru stable release updates] and [https://launchpad.net/~ubuntu-release release teams] |
To be carried out by: nominated stable release manager, with support from the [[https://launchpad.net/~ubuntu-sru|stable release updates]] and [[https://launchpad.net/~ubuntu-release|release]] teams |
Line 10: | Line 8: |
Planning stages, for LTS point releases: 1. Discuss candidates for new or improved hardware support with affected parties, including the Canonical support team (via Steve George) and the Ubuntu kernel team. 1. Establish a hit-list of bugs to fix in the point release. |
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 1. 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. |
Line 14: | Line 16: |
Release minus 2 months: 1. Process stable release updates [[StableReleaseUpdates|as normal]]. For hardware-enabling fixes, the package should be tested on the affected hardware prior to submitting to sign-off for -proposed. |
|
Line 15: | Line 20: |
1. Liaise with IS, QA, and certification to arrange for testing resources. | 1. Liaise with IS, QA, community and certification to arrange for testing resources. |
Line 17: | Line 22: |
Process stable release updates [:StableReleaseUpdates:as normal]. Once an acceptable number of bugs is believed to be fixed, start building test CD images: 1. If the kernel or associated modules has 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. |
Release minus 1 month: 1. In coordination with QA, verify that all candidate bugs are fixed. 1. Upload a new `base-files` package to -proposed to bump the `lsb_release` description ([[http://changelogs.ubuntu.com/changelogs/pool/main/b/base-files/base-files_4.0.1ubuntu5.8.04.8/changelog|example for 8.04.4]]). Do not change the DISTRIB_RELEASE value, which is used programmatically by third-party software. 1. 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. 1. Notify Evan Dandrea to update umenu and wubi for the point release. |
Line 20: | Line 28: |
1. Change `cdimage/bin/run-germinate` and `debian-cd/CONF.sh` to build from -proposed temporarily. If live CDs need to be built, also modify `cdimage/bin/buildlive`. 1. Build CD images (which will be published and smoke-test in some convenient environment to check for obvious failures. 1. Contact IS, QA, and/or certification as appropriate to request testing. 1. Once testing is verified to be complete, release images as final, and move the previous images to `old-releases.ubuntu.com`. TODO much more detail here |
1. Change `cdimage/bin/run-germinate` and `debian-cd/CONF.sh` to build from -proposed temporarily. 1. Build CD images (which will be published on cdimage.ubuntu.com) and smoke-test in some convenient environment to check for obvious failures. |
Line 25: | Line 31: |
TODO: * actual release process * `lsb_release` et al? * Anything else? |
Release minus 3 weeks: 1. Contact IS, QA, and/or certification as appropriate to request testing for hardware recertification. 1. Iterate CD images as needed based on testing feedback, in coordination with the kernel team. Release minus 6 days: 1. Once testing is verified to be complete, move packages to -updates. 1. 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. 1. Notify web publishing team (Matthew Nuzum) of the upcoming point release. * 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: 1. release images as final, and move the previous images to `old-releases.ubuntu.com`: * Check with James Troup whether the previous point release needs to be moved off before prepublishing due to mirror space constraints. * Prepublish images: {{{DIST=lucid for-project ubuntu publish-release ubuntu-server/daily 20100708 server poolonly}}} (similar for alternates, desktops, etc.) * TODO much more detail here * Notify Matthew Nuzum to update the iso URLs on the ubuntu.com website 1. Create a snapshot of the archive: {{{lp_archive@cocoplum:~$ point-release-snapshot lucid lucid.1-security-updates-snapshot}}} which will create a hardlink farm in `~lp_archive/point-releases/`. 1. File a bug on [[https://bugs.launchpad.net/ubuntu-website/+bugs|ubuntu-website]] to have https://help.ubuntu.com/community/UbuntuHashes updated. 1. work with release and web publishing team to monitor mirror pickup * verify download from ubuntu.com * verify download from one of the mirrors 1. send the announcement mail (see archives for past examples) * ubuntu-announce * ubuntu-release 1. notify press release team (Gerry Carr) - if needed. Release +1 day: 1. restore the .manifest.full file on releases.ubuntu.com 1. send out update to people running previous LTS (after migration testing completed). 1. get final summary of updates for release(see lucid-updates.py script), and publish to ??? 1. gather post mortem info, and start brainstorming... ---- CategoryProcess |
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.
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.
- Notify Evan Dandrea to update umenu and wubi for the point release.
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 and debian-cd/CONF.sh to build from -proposed temporarily.
- Build CD images (which will be published on cdimage.ubuntu.com) and smoke-test in some convenient environment to check for obvious failures.
Release minus 3 weeks:
- 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 6 days:
- Once testing is verified to be complete, move packages to -updates.
- 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.
- Notify web publishing team (Matthew Nuzum) of the upcoming point release.
- 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:
release images as final, and move the previous images to old-releases.ubuntu.com:
- Check with James Troup whether the previous point release needs to be moved off before prepublishing due to mirror space constraints.
- Prepublish images:
DIST=lucid for-project ubuntu publish-release ubuntu-server/daily 20100708 server poolonly (similar for alternates, desktops, etc.)
- TODO much more detail here
- Notify Matthew Nuzum to update the iso URLs on the ubuntu.com website
- Create a snapshot of the archive:
lp_archive@cocoplum:~$ point-release-snapshot lucid lucid.1-security-updates-snapshot
which will create a hardlink farm in ~lp_archive/point-releases/.
File a bug on ubuntu-website 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
- 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 post mortem info, and start brainstorming...
PointReleaseProcess (last edited 2022-02-22 09:39:35 by sil2100)