NewReleaseCycleProcess

Differences between revisions 8 and 20 (spanning 12 versions)
⇤ ← Revision 8 as of 2007-10-31 18:59:19 →
Size: 4756
Editor: 12
Comment: driver
← Revision 20 as of 2008-09-30 18:20:45 → ⇥
Size: 5551
Editor: c-76-124-0-181
Comment: Notify the InstallerTeam to add the intro back.
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
 1. Contact Soyuz development/production teams to ensure that they will be ready to create the new distrorelease on time.  1. Contact Soyuz development/production teams to ensure that they will be ready to create the new distroseries on time.
Line 13: Line 13:
  * wiki
  * Fridge calendar?		   * Create codenameReleaseSchedule page
  * Update ReleaseSchedule
  * Update Fridge calendar?
Line 20: Line 21:
 1. File an RT ticket asking for distrorelease-changes to be set up.  1. File an RT ticket asking for distroseries-changes to be set up.
Line 24: Line 25:
 1. Change driver for previous distrorelease to `ubuntu-core-dev`.
 1. Notify a Launchpad admin to create new distrorelease with status `FROZEN`.		  1. Change driver for previous distroseries to `ubuntu-core-dev`.
 1. Notify a Launchpad admin to create new distroseries with status `FROZEN`.
Line 28: Line 29:
 1. Notify Colin Watson to set up seed mirrors and germinate output for the new distrorelease.
 1. Reject any queued uploads to `RELEASE` pocket of previous distrorelease.		  1. Notify Colin Watson to set up seed mirrors and germinate output for the new distroseries.
 1. Reject any queued uploads to `RELEASE` pocket of previous distroseries.
Line 31: Line 32:
 1. Check that the new distrorelease exists with status `FROZEN`, and that the previous distrorelease has status `CURRENT`.
 1. Notify Soyuz production team to run `lp_publish:$ LPCONFIG=ftpmaster ./scripts/ftpmaster-tools/initialise-from-parent.py <new-distrorelease-name>` on drescher (takes around 8 minutes).
 1. Verify hard-coded parameters in Soyuz shell-scripts: './cronscripts/publishing/cron.germinate' and './cronscripts/publishing/gen-contents/generate-contents'.
 1. Run the publisher once: `lp_publish:$ LPCONFIG=ftpmaster ./scripts/publish-distro.py -d ubuntu -vv -A -s DRN -s DRN-updates -s DRN-security -s DRN-proposed -s DRN-backports` where DRN is the new distrorelease name. This run will create the proper archive indexes for all suites (takes around 25 minutes).
 1. Compare `dists` trees for previous and current distrorelease and sign off on any differences; the only differences should be the distrorelease name.		  1. Check that the new distroseries exists with status `FROZEN`, and that the previous distroseries has status `CURRENT`.
 1. Notify Soyuz production team to run `lp_publish:$ LPCONFIG=ftpmaster ./scripts/ftpmaster-tools/initialise-from-parent.py <new-distroseries-name>` on drescher (takes around 8 minutes).
 1. Run the publisher once: `lp_publish:$ LPCONFIG=ftpmaster ./scripts/publish-distro.py -d ubuntu -vv -A -s DSN -s DSN-updates -s DSN-security -s DSN-proposed -s DSN-backports` where DSN is the new distroseries name. This run will create the proper archive indexes for all suites (takes around 25 minutes).
 1. Compare `dists` trees for previous and current distroseries and sign off on any differences; the only differences should be the distroseries name.
Line 37: Line 37:
 1. Similarly, run the publisher once for the `partner` repository: `lp_publish:$ LPCONFIG=ftpmaster ./scripts/publish-distro.py -d ubuntu -vv -A -s DSN -s DSN-updates -s DSN-security -s DSN-proposed -s DSN-backports --partner -R /srv/launchpad.net/ubuntu-archive/ubuntu-partner/dists`; compare and sign off on any differences.
Line 39: Line 40:
 1. Notify Colin Watson to modify various reports (`britney`, `anastacia`, `jessica`) to point to the new distrorelease.
 1. Notify Scott James Remnant to set up `merge-o-matic` to point to the new distrorelease.		  1. Notify Colin Watson to modify various reports (`britney`, `anastacia`, `jessica`) to point to the new distroseries.
 1. Notify Scott James Remnant to set up `merge-o-matic` to point to the new distroseries.
Line 42: Line 43:
 1. Notify a Launchpad admin to set the status of the new distrorelease to `DEVELOPMENT`.  1. Notify a Launchpad admin to set the status of the new distroseries to `DEVELOPMENT`.
Line 45: Line 46:
 1. Ask Adam Conrad to bootstrap the build-RELEASE-live chroot on the buildds for the livefs builds
Line 47: Line 49:
 1. Update the default release in popcon.ubuntu.com and update the component list
 1. Notify a member of the InstallerTeam to add the introductory message back to Ubiquity.
Line 52: Line 56:
 1. Merge `devscripts`, `lintian`, and `vim` if necessary and update lists of Ubuntu release names to include the new release name.  1. Merge `apt-show-versions`, `devscripts`, `lintian`, and `vim` if necessary and update lists of Ubuntu release names to include the new release name.
Line 57: Line 61:
 1. Add the date of the previous release to `calendar.ubuntu` in `bsdmainutils`
 1. QA team will triage the {{{+nominations}}} bugs list, declining non-SRU candidate nominations and re-target bugs. The release team will evaluate the remaining list, accepting good SRU candidates

To be carried out by: Adam Conrad and Ubuntu Release Manager

Goals:

  • Unblock development process for new release as quickly as possible.
  • Prepare for first milestone CD release.

Previous release minus 1 month:

  1. Contact Soyuz development/production teams to ensure that they will be ready to create the new distroseries on time.
  2. Remind toolchain developers to begin preparing the new toolchain.
  3. Confirm final schedule for the new release and communicate key release dates
    • Create codenameReleaseSchedule page

    • Update ReleaseSchedule

    • Update Fridge calendar?
    • Canonical calendars

Previous release minus 2 weeks:

  1. Double-check with Soyuz development/production teams.
  2. File an RT ticket asking for distroseries-changes to be set up.

Previous release plus 1 day:

  1. Change driver for previous distroseries to ubuntu-core-dev.

  2. Notify a Launchpad admin to create new distroseries with status FROZEN.

  3. Create a milestone named ubuntu-$version in the release

  4. Create new seed branches based on those for the previous release, and push them to the appropriate subdirectories of bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/.

  5. Notify Colin Watson to set up seed mirrors and germinate output for the new distroseries.

  6. Reject any queued uploads to RELEASE pocket of previous distroseries.

  7. Disable the Soyuz publisher cron jobs.

  8. Check that the new distroseries exists with status FROZEN, and that the previous distroseries has status CURRENT.

  9. Notify Soyuz production team to run lp_publish:$ LPCONFIG=ftpmaster ./scripts/ftpmaster-tools/initialise-from-parent.py <new-distroseries-name> on drescher (takes around 8 minutes).

  10. Run the publisher once: lp_publish:$ LPCONFIG=ftpmaster ./scripts/publish-distro.py -d ubuntu -vv -A -s DSN -s DSN-updates -s DSN-security -s DSN-proposed -s DSN-backports where DSN is the new distroseries name. This run will create the proper archive indexes for all suites (takes around 25 minutes).

  11. Compare dists trees for previous and current distroseries and sign off on any differences; the only differences should be the distroseries name.

    • ~lp_archive/bin/compare-archives or other tools may be useful for this - XXX nominate one and install in a standard location on drescher

  12. Similarly, run the publisher once for the partner repository: lp_publish:$ LPCONFIG=ftpmaster ./scripts/publish-distro.py -d ubuntu -vv -A -s DSN -s DSN-updates -s DSN-security -s DSN-proposed -s DSN-backports --partner -R /srv/launchpad.net/ubuntu-archive/ubuntu-partner/dists; compare and sign off on any differences.

  13. Verify that the partner repository has been created on archive.canonical.com as a result of this process; if not, notify the Soyuz developers to fix it and check that this happens.

  14. Re-enable the Soyuz publisher cron jobs.

  15. Notify Colin Watson to modify various reports (britney, anastacia, jessica) to point to the new distroseries.

  16. Notify Scott James Remnant to set up merge-o-matic to point to the new distroseries.

  17. Notify toolchain developers to upload new toolchain. Iterate uploads as necessary until this has successfully built on all architectures.

  18. Notify a Launchpad admin to set the status of the new distroseries to DEVELOPMENT.

  19. Inform #ubuntu-devel and ubuntu-devel-announce that the new release is now open for uploads, pointing to merge-o-matic output.

  20. Create data/RELEASE, tools/RELEASE, and tools/boot/RELEASE directories in debian-cd based on corresponding directories for the previous release. Set OFFICIAL to "Alpha" in CONF.sh for the new release. Adjust cdimage code to be aware of the new release.

  21. Ask Adam Conrad to bootstrap the build-RELEASE-live chroot on the buildds for the livefs builds
  22. Turn live filesystem and cdimage cron jobs back on.

  23. Update UbuntuDevelopment to reflect the code name of the current release

  24. Update the default release in popcon.ubuntu.com and update the component list

  25. Notify a member of the InstallerTeam to add the introductory message back to Ubiquity.

First weeks, after toolchain complete:

  1. Merge base-files if necessary and change /etc/issue, /etc/issue.net, /etc/motd, and /etc/lsb-release to refer to the new release.

  2. Merge debootstrap if necessary and create a bootstrap script for the new release as a copy of the previous one.

  3. Merge apt-show-versions, devscripts, lintian, and vim if necessary and update lists of Ubuntu release names to include the new release name.

  4. Merge cdrom-detect, choose-mirror, and iso-scan if necessary and update cdrom/suite and /mirror/suite debconf templates to include a choice for the new release and update any previous default.

  5. Merge the rest of the installer in dependency order, ending with debian-installer once all other installer components have built successfully on all architectures.

  6. Notify oem-config and ubiquity maintainer(s) to run debian/rules update, adjust as necessary to account for changes, and upload.

  7. Upload a new version of WinFOSS with new version numbers (heno)

  8. Add the date of the previous release to calendar.ubuntu in bsdmainutils

  9. QA team will triage the +nominations bugs list, declining non-SRU candidate nominations and re-target bugs. The release team will evaluate the remaining list, accepting good SRU candidates

  10. Continue on MilestoneProcess.

NewReleaseCycleProcess (last edited 2024-05-09 04:29:15 by wgrant)