NewReleaseCycleProcess

Differences between revisions 1 and 62 (spanning 61 versions)
⇤ ← Revision 1 as of 2007-09-17 17:53:43 →
Size: 4371
Editor: 82-69-40-219
Comment: moved from Canonical wiki
← Revision 62 as of 2010-10-11 11:01:04 → ⇥
Size: 8548
Editor: eth0
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
To be carried out by: Adam Conrad and Ubuntu Release Manager <<TableOfContents>>
Line 3: Line 3:
Goals: To be carried out by: La``Mont Jones and Ubuntu Release Manager

== Goals ==
Line 8: Line 10:
Previous release minus 1 month: == Stages ==
Line 10: Line 12:
 1. Contact Soyuz development/production teams to ensure that they will be ready to create the new distrorelease on time. Bugs related to this process are tagged with [[https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=new-release-cycle-process|new-release-cycle-process]]. If you discover new glitches or things that can be automated, please file a bug with that tag.

=== Previous release minus 1 month ===

 1. Contact Soyuz development/production teams to ensure there are no known outstanding issues that will prevent on-time opening of the new distroseries.
Line 12: Line 18:
 1. Confirm final schedule for the new release and communicate key release dates
  * Create codenameReleaseSchedule page
  * Update ReleaseSchedule
  * Update Fridge calendar?
  * Canonical calendars
Line 13: Line 24:
Previous release minus 2 weeks: === Previous release minus 2 weeks ===
Line 16: Line 27:
 1. File an RT ticket asking for distrorelease-changes to be set up.  1. Ask for the maillist distroseries-changes to be set up by sending email to ubuntu-platform@rt.canonical.com to file an RT ticket.
Line 18: Line 29:
Previous release plus 1 day: === Previous release plus 1 day ===
Line 20: Line 31:
 1. Notify a Launchpad admin to create new distrorelease with status `FROZEN`.  1. Change driver (a.k.a. "Release manager") for previous distroseries to `ubuntu-core-dev`by https://launchpad.net/ubuntu/distroseries/+driver.
 1. 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/`.
 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.
 1. Disable the Soyuz publisher cron jobs.
 1. Notify a Launchpad admin to create new distroseries with status `FROZEN`. (Note that at the moment this breaks some parts of Launchpad until the new distroseries is initialised, so do this as close to running `initialise-from-parent` as possible.)
Line 22: Line 38:
 1. Create new seed branches based on those for the previous release, and push them to the appropriate subdirectories of `sftp://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/`.
 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. Disable the Soyuz publisher cron jobs.
 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. 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.
  * `~ubuntu-archive/bin/compare-archives` or other tools may be useful for this - XXX nominate one and install in a standard location on drescher
 1. Verify hard-coded parameters in Soyuz shell-scripts: './cronscripts/publishing/cron.germinate' and './cronscripts/publishing/gen-contents/generate-contents'.
 1. Re-enable the Soyuz publisher cron jobs.
 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. Check that the new distroseries exists with status `FROZEN`, and that the previous distroseries has status `CURRENT`.
 1. Create symbolic links `/srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.DSN.restricted -> more-extra.override.DSN.main`, `/srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.DSN.universe -> more-extra.override.DSN.main`, and `/srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.DSN.multiverse -> more-extra.override.DSN.main` on cocoplum, where DSN is the new distroseries name.
 1. Notify Soyuz production team to run `lp_publish:$ LPCONFIG=ftpmaster ./scripts/ftpmaster-tools/initialise-from-parent.py -a amd64,armel,i386,powerpc <new-distroseries-name>` on cocoplum (takes around 8 minutes).
  * If the set of active architectures changed in the previous cycle, update the comma-separated list passed to the `-a` option.
 1. Notify James Westby/Jonathan Lange to initialize the branches for the new series.
 1. Run the publisher once: `lp_publish:$ LPCONFIG=ftpmaster-publish ./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, that custom uploads (`installer-*`, `dist-upgrader-all`, and `i18n`) are missing from `dists/DSN/main`, and that `Release.gpg` does not yet exist (this will be created when the full publisher cron job next runs).
  * `~lp_archive/bin/compare-archives` or other tools may be useful for this - XXX nominate one and install in a standard location on cocoplum
 1. Make sure that no packages are pending publication in DSN's `partner` repository (use `lp-remove-package.py` to remove all source packages currently published in the previous distroseries), since the partner team does not want these to be propagated automatically. (Julian Edwards has promised to change Launchpad's default behaviour here. [This is indeed fixed now, please remove this comment once you've verified it works for Natty opening. ''--Julian''])
 1. Similarly, run the publisher once for the `partner` repository: `lp_publish:$ LPCONFIG=ftpmaster-publish ./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. Due to the previous step, the new `Packages` and `Sources` files should be empty.
 1. Run the script to initialize the package sets from the previous release.
 1. Re-enable the Soyuz publisher cron jobs and wait for the first run to complete.
 1. 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.
 1. Prepare and upload new buildd chroots.
 1. Notify rosetta@launchpad.net to open Launchpad translations for the new distroseries.
 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 36: Line 56:
 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`.
 1. Notify a Launchpad admin to enable PPAs for the new distroseries by enabling virtualization support on https://launchpad.net/ubuntu/DSN/{i386,amd64}/+admin
 1. Check with James Westby/Jonathan Lange that the new branches are available.
Line 39: Line 61:
 1. Turn live filesystem and cdimage cron jobs back on.
 1. Update UbuntuWiki:UbuntuDevelopment to reflect the code name of the current release		  1. Ask La``Mont Jones to bootstrap the build-RELEASE-live chroot on the buildds for the livefs builds
 1. Update UbuntuDevelopment, ArchiveAdministration to reflect the code name of the current release
 1. Notify Michael Vogt to 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.
 1. Notify James Westby to enable kerneloops.
 1. Target issues from the previous release's release notes to be fixed in the new release.
Line 42: Line 68:
First weeks, after toolchain complete: === First weeks, after toolchain complete ===
Line 44: Line 70:
 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.
 1. Merge `debootstrap` if necessary and create a bootstrap script for the new release as a copy of the previous one.
 1. Merge `devscripts`, `lintian`, and `vim` if necessary and update lists of Ubuntu release names to include the new release name.		  1. Merge `base-files` if necessary and change `/etc/issue`, `/etc/issue.net`, and `/etc/lsb-release` to refer to the new release.
 1. Merge `debootstrap` if necessary and create a bootstrap script for the new release as a copy of the previous one (currently, we can just make the new one a symlink to `gutsy`, as it hasn't changed since then).
 1. Merge `devscripts`, `lintian`, `vim`, `emacs-goodies-el`, and `system-tools-backends` if necessary and update lists of Ubuntu release names to include the new release name.
 1. Update `/usr/share/python-apt/templates/Ubuntu.info` in `python-apt` to include the new release name.
Line 50: Line 77:
 1. Upload a new version of WinFOSS with new version numbers (heno)  1. Turn live filesystem and cdimage cron jobs back on.
 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
Line 52: Line 81:

----
CategoryProcess

Contents

  1. Goals
  2. Stages
    1. Previous release minus 1 month
    2. Previous release minus 2 weeks
    3. Previous release plus 1 day
    4. First weeks, after toolchain complete

To be carried out by: LaMont Jones and Ubuntu Release Manager

Goals

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

Stages

Bugs related to this process are tagged with new-release-cycle-process. If you discover new glitches or things that can be automated, please file a bug with that tag.

Previous release minus 1 month

  1. Contact Soyuz development/production teams to ensure there are no known outstanding issues that will prevent on-time opening of the new distroseries.
  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. Ask for the maillist distroseries-changes to be set up by sending email to ubuntu-platform@rt.canonical.com to file an RT ticket.

Previous release plus 1 day

  1. Change driver (a.k.a. "Release manager") for previous distroseries to ubuntu-core-devby https://launchpad.net/ubuntu/distroseries/+driver.

  2. 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/.

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

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

  5. Disable the Soyuz publisher cron jobs.

  6. Notify a Launchpad admin to create new distroseries with status FROZEN. (Note that at the moment this breaks some parts of Launchpad until the new distroseries is initialised, so do this as close to running initialise-from-parent as possible.)

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

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

  9. Create symbolic links /srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.DSN.restricted -> more-extra.override.DSN.main, /srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.DSN.universe -> more-extra.override.DSN.main, and /srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.DSN.multiverse -> more-extra.override.DSN.main on cocoplum, where DSN is the new distroseries name.

  10. Notify Soyuz production team to run lp_publish:$ LPCONFIG=ftpmaster ./scripts/ftpmaster-tools/initialise-from-parent.py -a amd64,armel,i386,powerpc <new-distroseries-name> on cocoplum (takes around 8 minutes).

    • If the set of active architectures changed in the previous cycle, update the comma-separated list passed to the -a option.

  11. Notify James Westby/Jonathan Lange to initialize the branches for the new series.

  12. Run the publisher once: lp_publish:$ LPCONFIG=ftpmaster-publish ./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).

  13. Compare dists trees for previous and current distroseries and sign off on any differences; the only differences should be the distroseries name, that custom uploads (installer-*, dist-upgrader-all, and i18n) are missing from dists/DSN/main, and that Release.gpg does not yet exist (this will be created when the full publisher cron job next runs).

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

  14. Make sure that no packages are pending publication in DSN's partner repository (use lp-remove-package.py to remove all source packages currently published in the previous distroseries), since the partner team does not want these to be propagated automatically. (Julian Edwards has promised to change Launchpad's default behaviour here. [This is indeed fixed now, please remove this comment once you've verified it works for Natty opening. --Julian])

  15. Similarly, run the publisher once for the partner repository: lp_publish:$ LPCONFIG=ftpmaster-publish ./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. Due to the previous step, the new Packages and Sources files should be empty.

  16. Run the script to initialize the package sets from the previous release.
  17. Re-enable the Soyuz publisher cron jobs and wait for the first run to complete.

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

  19. Prepare and upload new buildd chroots.

  20. Notify rosetta@launchpad.net to open Launchpad translations for the new distroseries.

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

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

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

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

  25. Notify a Launchpad admin to enable PPAs for the new distroseries by enabling virtualization support on https://launchpad.net/ubuntu/DSN/{i386,amd64}/+admin

  26. Check with James Westby/Jonathan Lange that the new branches are available.

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

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

  29. Ask LaMont Jones to bootstrap the build-RELEASE-live chroot on the buildds for the livefs builds

  30. Update UbuntuDevelopment, ArchiveAdministration to reflect the code name of the current release

  31. Notify Michael Vogt to update the default release in popcon.ubuntu.com and update the component list

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

  33. Notify James Westby to enable kerneloops.
  34. Target issues from the previous release's release notes to be fixed in the new release.

First weeks, after toolchain complete

  1. Merge base-files if necessary and change /etc/issue, /etc/issue.net, 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 (currently, we can just make the new one a symlink to gutsy, as it hasn't changed since then).

  3. Merge devscripts, lintian, vim, emacs-goodies-el, and system-tools-backends if necessary and update lists of Ubuntu release names to include the new release name.

  4. Update /usr/share/python-apt/templates/Ubuntu.info in python-apt to include the new release name.

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

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

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

  8. Turn live filesystem and cdimage cron jobs back on.

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

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

  11. Continue on MilestoneProcess.

CategoryProcess

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