MilestoneRhythm

Differences between revisions 1 and 26 (spanning 25 versions)
Revision 1 as of 2006-06-19 15:55:11
Size: 2472
Editor: ALagny-109-1-2-23
Comment:
Revision 26 as of 2008-08-06 16:39:27
Size: 5715
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/milestone-rhythm
 * '''Created''': [[Date(2006-06-19T15:55:11Z)]] by ColinWatson
 * '''Contributors''': ColinWatson
* '''Packages affected''':
 * '''Launchpad Entry''': UbuntuSpec:milestone-rhythm
 * '''Created''': <<Date(2006-06-19T15:55:11Z)>> by ColinWatson
 * '''Contributors''': ColinWatson, AdamConrad, ScottJamesRemnant, TollefFogHeen
Line 10: Line 9:
Processes and plans for milestone release preparation.
Line 11: Line 12:

We tend to do a lot of things leading up to milestone releases, such as clear out pending promotions/demotions, check britney uninstallables and out-of-date output, clear out bits of queue/new, etc. This specification documents what needs to be done, how frequently, and when it should be done, in relation to the actual ISO-building and release process.
Line 14: Line 17:
== Scope ==  * New members of the archive administration and milestone release management teams need to come up to speed quickly.
 * Milestone release managers want a checklist of things to do during milestone preparation to ensure that quality is as high as possible.
 * Milestone release managers want as many tasks as possible to be automated or simple so that milestone releases can be prepared regularly and frequently.
Line 16: Line 21:
== Design == == Routine technical tasks ==
Line 18: Line 23:
== Implementation == The following tasks need to be performed frequently by archive administrators, and should be reviewed at the start of milestone release preparation:
Line 20: Line 25:
=== Code ===  * clear out sync requests daily
 * clear out bits of the NEW queue daily (particularly during sync periods)
 * clear out pending main/universe promotions/demotions at least weekly (http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt)
 * clear out pending removals at least weekly (both requested and `archive-cruft-check`-driven)
 * sync priority overrides at least weekly (http://people.ubuntu.com/~ubuntu-archive/priority-mismatches.txt)
Line 22: Line 31:
=== Data preservation and migration === The following tasks need to be performed occasionally by the milestone release managers and anyone else interested in helping, and should be reviewed during milestone release preparation:
Line 24: Line 33:
== Outstanding issues ==  * check britney uninstallables and out-of-date output daily (http://people.ubuntu.com/~ubuntu-archive/testing/feisty_probs.html)
 * check that ISOs actually work as frequently as is convenient
  * check for .OVERSIZED files daily, and do something about them (may require coordination with derivative leads)
Line 26: Line 37:
== BoF agenda and discussion == The following tests need to be performed occasionally and may be part of milestone release preparation, depending on the desired quality/cost trade-off for the milestone in question:
Line 28: Line 39:
Raw notes:  * [[UbuntuSpec:auto-dist-upgrade-testing|upgrade testing]]
 * [[UbuntuSpec:frequent-rebuild-testing|buildability tests]]
 * update app-install-data desktop file database (see GnomeAppInstallDesktopDatabaseUpdate for details, mvo does that regularly).
Line 30: Line 43:
Technical routine, partly for milestone preparation, partly to make sure stuff is done regularly: Where possible and sensible, we will produce automatic reports of at least some of the above which are mailed to the `ubuntu-archive` and `ubuntu-release` teams as appropriate (and perhaps others) daily.
Line 32: Line 45:
 * clear out pending anastacia promotions/demotions (http://people.ubuntu.com/~cjwatson/anastacia.txt)
 * check britney uninstallables and out-of-date output (http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html)
 * clear out bits of queue/new (particularly during sync periods)
 * clear out sync requests
 * clear out pending removals (both requested and `archive-cruft-check`-driven)
 * sync priority fields (http://people.ubuntu.com/~cjwatson/jessica.txt)
SoyuzSpec:overrides-consistency-check requests writing a script to check for out-of-sync components, sections, and priorities between architectures, since it is slightly too easy to produce such overrides by accident during routine archive maintenance.
Line 39: Line 47:
 * check that ISOs actually work
  * check for .OVERSIZED files and actually do something about them
 * upgrade testing? (but should be automated)
 * buildability tests
The [[http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt|sync blacklist]] lists sources that cannot be synced from Debian for various reasons. In particular, this blacklist includes sources which have been modified in Ubuntu and whose binaries have been moved to other source packages, which is a situation that generally needs to be resolved by those responsible for those source packages in Ubuntu. This needs occasional gardening.
Line 44: Line 49:
Produce reports of at least some of the above which are mailed to `ubuntu-archive` (and perhaps others) daily? == Milestone release processes ==
Line 46: Line 51:
Should write script to check for out-of-sync components/sections/priorities(?) across architectures. The following checklist should be followed by milestone release managers. (Those people should feel free to amend this if experience demonstrates that other tasks are necessary.)
Line 48: Line 53:
Publicise the sync blacklist (binaries moved around).

Social routine:

 * check that everyone who cares has landed everything major they need to (or talk them out of it)
 * announce milestone freeze on -devel-announce(?) and #ubuntu-devel topic
 * set distro to frozen in Soyuz temporarily (and make sure that unapproved is cleaned out afterwards)
 * warn QA of upcoming release
 * warn doc team to prepare web page about changes since last milestone (ideally do this a few days in advance)
 * prepare release announcement (should basically just refer to web page); somebody needs to go over DISTRO-changes to make sure everything relevant is in there
 * Release (and if necessary, beat up `publish-release` until it works)
 * verify that all mirrors have images
 * send announcement (and argue with people about where it goes; current opinion seems to be `ubuntu-devel-announce` for non-beta/RC/final releases, and Bcc to `fridge-devel`)
 * [...]
 * PROFIT
 * A few days in advance of the planned milestone release date, ask the marketing team (ubuntu-marketing@lists.ubuntu.com) to prepare a web page about the changes since the last milestone.
 * Check that core developers have landed everything major they need to land (or talk them out of it).
 * Warn the QA team of the upcoming milestone release.
 * Tell Jeff Bailey that we're getting close to a release and ask for re-certification on our test hardware.
 * Announce the milestone freeze on the #ubuntu-devel topic and possibly `ubuntu-devel-announce`. There is generally no need to tell people to hold off on uploads, as they will be held automatically by Soyuz once the next task is performed.
 * Set the distrorelease to FROZEN in Soyuz temporarily.
 * Stop all live filesystem and cdimage cron jobs.
 * Clear out the testing grid
 * Test and iterate uploads as required, make sure to clear the testing grid for each iteration.
 * Go over DISTRORELEASE-changes since the last milestone to make sure that all relevant major changes have been documented in the milestone's web page.
 * Prepare the release announcement (this should refer to the web page prepared by the doc team rather than going into details of changes itself).
 * Publish the milestone CD images. This usually requires mangling the HEADER.html in the directory where the images are stored, since publish-release isn't smart enough to do the right thing there.
 * Verify that all mirrors have images.
 * Send the release announcement (current opinion on the target for the announcement seems to be `ubuntu-devel-announce` for non-beta/RC/final releases, and Bcc to `ubuntu-news-team`).
 * Set the distrorelease back to DEVELOPMENT.
 * Clear out any pending entries in the UNAPPROVED queue.
 * Turn live filesystems and cdimage cron jobs back on.

Summary

Processes and plans for milestone release preparation.

Rationale

We tend to do a lot of things leading up to milestone releases, such as clear out pending promotions/demotions, check britney uninstallables and out-of-date output, clear out bits of queue/new, etc. This specification documents what needs to be done, how frequently, and when it should be done, in relation to the actual ISO-building and release process.

Use cases

  • New members of the archive administration and milestone release management teams need to come up to speed quickly.
  • Milestone release managers want a checklist of things to do during milestone preparation to ensure that quality is as high as possible.
  • Milestone release managers want as many tasks as possible to be automated or simple so that milestone releases can be prepared regularly and frequently.

Routine technical tasks

The following tasks need to be performed frequently by archive administrators, and should be reviewed at the start of milestone release preparation:

The following tasks need to be performed occasionally by the milestone release managers and anyone else interested in helping, and should be reviewed during milestone release preparation:

The following tests need to be performed occasionally and may be part of milestone release preparation, depending on the desired quality/cost trade-off for the milestone in question:

Where possible and sensible, we will produce automatic reports of at least some of the above which are mailed to the ubuntu-archive and ubuntu-release teams as appropriate (and perhaps others) daily.

overrides-consistency-check requests writing a script to check for out-of-sync components, sections, and priorities between architectures, since it is slightly too easy to produce such overrides by accident during routine archive maintenance.

The sync blacklist lists sources that cannot be synced from Debian for various reasons. In particular, this blacklist includes sources which have been modified in Ubuntu and whose binaries have been moved to other source packages, which is a situation that generally needs to be resolved by those responsible for those source packages in Ubuntu. This needs occasional gardening.

Milestone release processes

The following checklist should be followed by milestone release managers. (Those people should feel free to amend this if experience demonstrates that other tasks are necessary.)

  • A few days in advance of the planned milestone release date, ask the marketing team (ubuntu-marketing@lists.ubuntu.com) to prepare a web page about the changes since the last milestone.

  • Check that core developers have landed everything major they need to land (or talk them out of it).
  • Warn the QA team of the upcoming milestone release.
  • Tell Jeff Bailey that we're getting close to a release and ask for re-certification on our test hardware.
  • Announce the milestone freeze on the #ubuntu-devel topic and possibly ubuntu-devel-announce. There is generally no need to tell people to hold off on uploads, as they will be held automatically by Soyuz once the next task is performed.

  • Set the distrorelease to FROZEN in Soyuz temporarily.
  • Stop all live filesystem and cdimage cron jobs.
  • Clear out the testing grid
  • Test and iterate uploads as required, make sure to clear the testing grid for each iteration.
  • Go over DISTRORELEASE-changes since the last milestone to make sure that all relevant major changes have been documented in the milestone's web page.
  • Prepare the release announcement (this should refer to the web page prepared by the doc team rather than going into details of changes itself).
  • Publish the milestone CD images. This usually requires mangling the HEADER.html in the directory where the images are stored, since publish-release isn't smart enough to do the right thing there.
  • Verify that all mirrors have images.
  • Send the release announcement (current opinion on the target for the announcement seems to be ubuntu-devel-announce for non-beta/RC/final releases, and Bcc to ubuntu-news-team).

  • Set the distrorelease back to DEVELOPMENT.
  • Clear out any pending entries in the UNAPPROVED queue.
  • Turn live filesystems and cdimage cron jobs back on.


CategorySpec

MilestoneRhythm (last edited 2008-08-06 16:39:27 by localhost)