DTP 1.11.1 Schedule and Ramp-down Policy

Purpose

This document defines a schedule and set of ramp-down policies for the DTP 1.11.1 service release.

Schedule

DTP is on the Kepler SR1 release train as a +1 project. Those dates are [here].

• 1.11.1 RC1 - 8/19/2013
• 1.11.1 RC2 - 9/2/2013
• 1.11.1 RC3 - 9/9/2013
• 1.11.1 RC4 - 9/16/2013
• 1.11.1 Release - 9/27/2013

Things to Keep in Mind

• During the regular development phase and through RC1 and RC2, nightly builds take place from Monday to Thursday. Integration builds are done on Friday.
• DTP builds will take place at 5am (Shanghai time). (That is 2 PM PST.)
• Builds are pushed to the DTP update site on Tuesday AM Shanghai time. (Monday evening PST)
• During the RC phases, team lead or PMC approval is needed to update the code base. We will not be doing nightly builds, but will build as needed if "must fix" problems are found and fixed.

Ramp-down Cycles

Note: Builds occur on the days noted, at 5am (Shanghai time). The I-builds occur on the Friday before the +1 RC date.

• RC1
  • After the RC1 build, we will be in a Test and Fix phase and only delivering critical fixes
  • We will continue to do RC2 nightly builds during this period
  • If a RC1 re-spin is required, it will be requested on an as-needed basis
  • All commits must be approved by a team lead
  • After release, the code base will again be open for code delivery

• RC2
  • After this build, we will be in a Test and Fix phase and only delivering critical fixes
  • We will continue to do nightly RC3 builds during this period
  • If a RC2 re-spin is required, it will be requested on an as-needed basis
  • All commits must be approved by a team lead
  • After release, the codebase will again be open for code delivery

• After RC3
  • After the RC3 milestone release, we will be in a Test and Fix phase only and delivering critical, show-stopper bug fixes as necessary
  • There will be no nightly or integration builds during this period
  • If a build is required, it will be requested on an as-needed basis and any re-spin will be considered our RC4 candidate. If no build is required, the final RC3 candidate will become our RC4 candidate
  • Committers must annotate bugs proposed for inclusion in the release with risks and nature of fix
  • Committers must petition the DTP PMC using BZ for inclusion of specific bugs

• Release