MilestoneRhythm

Revision 3 as of 2006-06-20 07:38:25

Clear message

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

Design

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:

  • check britney uninstallables and out-of-date output daily (http://people.ubuntu.com/~cjwatson/testing/edgy_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)

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:

  • upgrade testing? (but should be automated)
  • buildability tests

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.

We will write 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. (Note that in the future some priorities may be legitimately out of sync between architectures.)

We will publicise the sync blacklist, which 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.

Implementation

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

Raw notes:

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

CategorySpec