Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

DTP 1.11 Schedule and Rampdown Policy

Purpose

This document defines a schedule and set of ramp-down policies for DTP 1.11 (Kepler).

Schedule

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

  • 1.11 M6 - March 18, 2013 (publicly available 3/22/13)
  • 1.11 M7 - May 6, 2013 (publicly available 5/10/13)
  • 1.11 RC1 - May 20, 2013 (publicly available 5/24/13)
  • 1.11 RC2 - May 27, 2013 (publicly available 5/31/13)
  • 1.11 RC3 - June 3, 2013 (publicly available 6/7/13)
  • 1.11 RC4 - June 10, 2013 (publicly available 6/14/13)
  • 1.11 Release - June 26, 2013

Prior to M6, DTP contribution to Kepler milestones are the same bits as DTP 1.10.2 (Juno SR2) builds.

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

Back to the top