PointReleaseProcess
3634
Comment: clarify split between week-of and day-of release activities
|
3794
document that readaheadlistupdate needs to be done before point releases too
|
Deletions are marked like this. | Additions are marked like this. |
Line 27: | Line 27: |
1. Upload a new `base-files` package to -proposed to bump the `lsb_release` version number ([http://changelogs.ubuntu.com/changelogs/pool/main/b/base-files/base-files_3.1.9ubuntu7.2/changelog example for 6.06.2]). | 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_3.1.9ubuntu7.2/changelog example for 6.06.2]). Do not change the DISTRIB_RELEASE value, which is used programmatically by third-party software. |
Line 39: | Line 39: |
1. Notify Scott James Remnant to perform a ReadaheadListUpdate |
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
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 committment 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 [:StableReleaseUpdates: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, 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 ([http://changelogs.ubuntu.com/changelogs/pool/main/b/base-files/base-files_3.1.9ubuntu7.2/changelog example for 6.06.2]). 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 and debian-cd/CONF.sh to build from -proposed temporarily. If live CDs need to be built, also modify cdimage/bin/buildlive.
- Build CD images (which will be published 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.
Notify Scott James Remnant to perform a ReadaheadListUpdate
Release:
release images as final, and move the previous images to old-releases.ubuntu.com:
- Prepublish images:
DIST=dapper ARCHES="i386 amd64 sparc powerpc" for-project ubuntu publish-release ubuntu-server/daily 20080110.1 server poolonly (similar for alternates, desktops, etc.)
- TODO much more detail here
- Prepublish images:
- Create a snapshot of the archive:
lp_archive@drescher:~$ point-release-snapshot dapper dapper.2-security-updates-snapshot
which will create a hardlink farm in ~lp_archive/point-releases/.
File a bug on [https://bugs.launchpad.net/ubuntu-website/+bugs ubuntu-website] to have https://help.ubuntu.com/community/UbuntuHashes updated.
TODO:
- Anything else?
- Standard criteria for adding -updates tag to bugs
PointReleaseProcess (last edited 2022-02-22 09:39:35 by sil2100)