ReleaseCycle

Differences between revisions 13 and 15 (spanning 2 versions)
Revision 13 as of 2005-04-24 01:14:23
Size: 1661
Editor: intern146
Comment: priority
Revision 15 as of 2005-04-28 07:31:32
Size: 4206
Editor: intern146
Comment: add BOF contributors
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
  * Contributors: MattZimmerman[[BR]]   * Contributors: MattZimmerman, ColinWatson, AdiAttar, JordiMallach[[BR]]
Line 14: Line 14:
  * Branch: [[BR]]
  * Malone Bug: [[BR]]
Line 18: Line 16:
  * UduSessions: 1, 4, 8, etc [[BR]]   * UduSessions: 1[[BR]]
Line 26: Line 24:
Our current release strategy has worked pretty well, but it has encountered some teething problems as new developers, documenters, translators, and so on have joined our community. We need to review and update it.
Line 29: Line 29:

[THIS IS INCOMPLETE.]

At the moment, our release cycle looks like the following:

 * T-18 weeks: seed freeze
 * T-13 weeks: upstream version freeze
 * T-12 weeks: remaining merges complete
 * T-8 weeks: feature freeze
 * T-5 weeks: preview freeze
 * T-4 weeks: preview release
 * T-1 week: final freeze
 * T: release

The Hoary release cycle exposed a few problems with this arrangement. Notably, there is no string freeze, and thus translators had problems keeping up to date; there is no point where we freeze the user interface that needs to be documented; we do not adequately notify relevant people of freeze exceptions; and the time allocated between feature freeze and the preview release is a little too short to allow new features to settle down.

We propose the following changes to the release cycle:

 * Remove seed freeze

 The usefulness of the seed freeze has proven to be limited. In practice, we have made necessary seed changes quite late in the cycle, and we always review the supportability of new packages in main regardless of when they are introduced. Instead of an artificial and false seed freeze, we will instead simply take other freeze conditions (upstream version freeze, feature freeze, etc.) into account when making seed changes. This codifies existing practice.

 * Move UVF and feature freeze one week earlier

 The gap between feature freeze and the preview release is too short, and a number of new features did not receive adequate testing before the Hoary preview. To alleviate the rush, we will move feature freeze one week earlier. Upstream version freeze will move one week earlier to correspond with this: in practice, we have been content to allow reasonable exceptions to the upstream version freeze, so this should not be a problem.

 * Institute string freeze

 After consultation with some Ubuntu translators, we will institute a string freeze, to coincide with preview freeze (T-5 weeks). At this point, no translatable strings outside documentation may change without prior confirmation. This should allow translators time to finish their work before the final release.

[TODO: UI freeze, doc string freeze, communication of freeze exceptions, release announcements?, adjusting syncage with GNOME releases, kernel non-security freeze, other stuff from mdz's notes]

Release Cycle

Status

Introduction

Review our experiences with the existing release strategy and discuss possible improvements

Rationale

Our current release strategy has worked pretty well, but it has encountered some teething problems as new developers, documenters, translators, and so on have joined our community. We need to review and update it.

Scope and Use Cases

Implementation Plan

[THIS IS INCOMPLETE.]

At the moment, our release cycle looks like the following:

  • T-18 weeks: seed freeze
  • T-13 weeks: upstream version freeze
  • T-12 weeks: remaining merges complete
  • T-8 weeks: feature freeze
  • T-5 weeks: preview freeze
  • T-4 weeks: preview release
  • T-1 week: final freeze
  • T: release

The Hoary release cycle exposed a few problems with this arrangement. Notably, there is no string freeze, and thus translators had problems keeping up to date; there is no point where we freeze the user interface that needs to be documented; we do not adequately notify relevant people of freeze exceptions; and the time allocated between feature freeze and the preview release is a little too short to allow new features to settle down.

We propose the following changes to the release cycle:

  • Remove seed freeze The usefulness of the seed freeze has proven to be limited. In practice, we have made necessary seed changes quite late in the cycle, and we always review the supportability of new packages in main regardless of when they are introduced. Instead of an artificial and false seed freeze, we will instead simply take other freeze conditions (upstream version freeze, feature freeze, etc.) into account when making seed changes. This codifies existing practice.
  • Move UVF and feature freeze one week earlier The gap between feature freeze and the preview release is too short, and a number of new features did not receive adequate testing before the Hoary preview. To alleviate the rush, we will move feature freeze one week earlier. Upstream version freeze will move one week earlier to correspond with this: in practice, we have been content to allow reasonable exceptions to the upstream version freeze, so this should not be a problem.
  • Institute string freeze After consultation with some Ubuntu translators, we will institute a string freeze, to coincide with preview freeze (T-5 weeks). At this point, no translatable strings outside documentation may change without prior confirmation. This should allow translators time to finish their work before the final release.

[TODO: UI freeze, doc string freeze, communication of freeze exceptions, release announcements?, adjusting syncage with GNOME releases, kernel non-security freeze, other stuff from mdz's notes]

Data Preservation and Migration

Packages Affected

User Interface Requirements

Outstanding Issues

UDU BOF Agenda

  • Everybody loves newer software
    • The backports mess
    • What are the valid use cases, and can we accomodate them within Ubuntu?
      • Making new packages available to users of stable releases
      • Making new versions of existing packages available to users of stable releases (at what granularity?)
  • Phases of freeze
  • Release rollup / checklist items
    • Artwork
    • Translations
      • String freeze
      • Installer translations
      • Non-langpack translations
      • Langpack translations
    • Documentation
      • Screenshots
      • Translations?
      • Behaviour changes
    • Kernel
    • Uploads of packages which go on the CD
    • Uploads to main
    • Uploads to universe

UDU Pre-Work

UbuntuDownUnder/BOFs/ReleaseCycle (last edited 2008-08-06 16:36:33 by localhost)