Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

DTP Ganymede Rampdown Policy

Back to DTP Main Page


This document defines a set of rampdown cycles for DTP 1.6. The goal is to ensure that DTP stability and completeness converges on the 1.6 release dates, while allowing mechanisms for changes as necessary. Since this document is about the rampdown, only cycles post DTP 1.6RC0 will be detailed below.

Since DTP 1.6 uses map files, committers can continue to deliver changes to CVS HEAD, and such changes are not automatically included in the build. Thus, this process concerns approved updates to the map files and hence changes to the code delivered by DTP 1.6. Given that any plug-in might need to be changed during the end game, the DTP PMC discourages substantial changes being released to CVS HEAD, which could then complicate the process of promoting only tightly constrained changes to the DTP 1.6 release stream through the map files.

Rampdown Cycle Phases

Testing Pass

A period of testing during which no changes are made to the DTP code line, unless approved by the PMC. Nightly builds will not be produced during this pass. In general, we ask everyone in the DTP community to test the target build as thoroughly as possible.

Testing & Fix Pass

A Testing Pass including bug fixes based on the approval policies described below. Nightly build will be produced during this period as necessary to make bug fixes available to the DTP community.

Rampdown Cycles

Builds Reminder

  • Nightly builds take place from Monday to Thursday. Integration builds takes place on Friday.
  • During a test phase, there are no builds. We take the build before the test phase and test it. If we run across extreme issues, we will respin and retest.
  • During the test/fix phase for RC1 and RC2, we will do regular daily builds. In test/fix phases for RC3 and RC4, where PMC approvals are needed, we will not build nightly, but will build as needed (5/29 and beyond).
  • On Push days, we will take the Monday Shanghai build (which is our Sunday at 2pm PST) and if it's good, we will push it to the update site that Monday evening (SH Tuesday a.m.). If things are not good, we will fix the issues and respin the build, taking the respun build and pushing it to the update site.
  • DTP builds will take place at 5am (Shanghai time).
  • In general, builds occur Mon - Fri at 2pm Shanghai time, which is equivalent to Sun - Thu 2pm PST.
  • DTP committers should refrain from updating map files for +/- 30 minutes around the start of the build, to avoid version inconsistencies in the map file set.
  • See the Build Transition page for additional details about regular DTP builds


DTP 1.6 Rampdown.jpg

DTP 1.6RC0(M7): May 5 (Monday)

  • Revision (April 7, 2008)
    • In an attempt to to avoid last-minute regressions, we are implementing a slightly longer testing cycle for the M7/RC0 milestone.
    • The new policy is as follows:
    • 1. Commits for DTP 1.6 M7 will be allowed through the build start time (5am Shanghai time as noted at on Tuesday, April 29th by 1:30pm PST.
    • 2. The testing period will start April 30 and last through May 2 so we are ready to push a build to the Ganymede site on May 5.
    • 3. Committers wishing to include additional bug fixes in M7 between April 30 and May 2 must provide the following in an associated Bugzilla entry:
      • Document the severity and impact of the bug, i.e. why should this be included in the milestone at such a late date?
      • Document the proposed resolution, risk, and validation testing that will occur by the committer
      • Petition the DTP PMC for permission to deliver the change to the build. At least two (2) of the four (4) PMC members must approve, with no PMC member objecting, for the bug to be authorized for the M7 build.
    • If a change meets all of these criteria, it can be delivered and we will continue testing with the next build that includes that fix.
    • If you have any questions about this policy, please send them to the dtp mailing lists (dtp-pmc or dtp-dev).
  • From Monday, 5/5, through Wednesday, 5/7: Testing Pass (formal test pass)
  • From Thursday, 5/8, through Friday, 5/16: Testing & Fix Pass: Standard DTP policies apply.

DTP 1.6RC1: May 19 (Monday)

  • From Monday, 5/19, through Tuesday, 5/20: Testing Pass
  • From Wednesday, 5/21, through Friday, 5/23: Testing & Fix Pass: All bugs must approved by project lead who must notify the dtp-pmc mailing list.

DTP 1.6RC2: May 26 (Monday)

  • From Monday, 5/26, through Wednesday, 5/28: Testing Pass
  • From Thursday, 5/29, through Friday, 5/30: Testing & Fix Pass: All bugs must approved by PMC. Project leads should petition the dtp-pmc mailing list for approval and any community member should do the same for bugs that they feel should be addressed in DTP 1.6.

DTP 1.6RC3: June 2 (Monday)

  • From Monday, 6/2, through Wednesday, 6/4: Testing Pass
  • From Thursday, 6/5, through Friday, 6/6: Testing & Fix Pass: All bugs must approved by PMC. Project leads should petition the dtp-pmc mailing list for approval and any community member should do the same for bugs that they feel should be addressed in DTP 1.6.

DTP 1.6RC4: June 9 (Monday)

  • From Monday, 6/9, through Ganymede release: Testing Pass
  • Post RC4 changes:
    • Only for severe bugs with substantial, demonstrated impact to users or adopters
    • Project lead must petition dtp-pmc
    • Project lead (or committer responsible for the code) must update bug with a description of severity, impact, risks, and outline/patch for proposed fix
    • All PMC members must grant approval using BZ flags on the specific bug
    • Modifications must be reviewed and approved (in BZ) by an additional committer on the same project
    • Only modified plug-ins (and associated features) are approved for update in the map files
    • Once the modification is available in a DTP build, the committer must test and verify (in BZ) that the modification works as expected and is not known to have introduced regressions or injected bugs elsewhere.

Additional RC Builds

Additional RC builds will be scheduled as necessary.

Back to the top