PointReleaseProcess

Differences between revisions 1 and 34 (spanning 33 versions)
⇤ ← Revision 1 as of 2007-12-13 15:17:02 →
Size: 2187
Editor: 82-69-40-219
Comment: initial incomplete draft
← Revision 34 as of 2011-02-11 23:39:48 → ⇥
Size: 5532
Editor: 99-191-111-134
Comment: update web team contact (Richard Lee) and add the image candidate build into the process flow
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.
 1. Canvas OEM and Support organizations for any bugs important to try to get fixed.
Line 17: Line 23:
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 29:
 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`, `debian-cd/CONF.sh`, and the cdimage crontab 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 32:
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. Turn off CRON jobs that will auto update into -updates until final images are tested.
 1. Build candidate release images and populate into iso tracker.
 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 (Richard Lee) 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 Web team (Richard Lee) 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. deactivate the just released "point release" milestone target
 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 feedback info for future improvements to process

----
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:

  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.

  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. Notify Evan Dandrea to update umenu and wubi for the point release.

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

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

  7. 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:

  1. Contact IS, QA, and/or certification as appropriate to request testing for hardware recertification.
  2. 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.
  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. Prepare change summary and release announcement
  5. Notify web publishing team (Richard Lee) 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 Web team (Richard Lee) to update the iso URLs on the ubuntu.com website
  2. 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/.

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

  4. work with release and web publishing team to monitor mirror pickup
    • verify download from ubuntu.com
    • verify download from one of the mirrors
  5. send the announcement mail (see archives for past examples)
    • ubuntu-announce
    • ubuntu-release
  6. 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)