Jump to: navigation, search

Difference between revisions of "DTP Ganymede Rampdown Policy"

Line 7: Line 7:
 
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.
 
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, since 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==
 
==Rampdown Cycle Phases==
  

Revision as of 15:17, 6 March 2008

Back to DTP Main Page

Status

[2/26/08]: This document is a draft and has not been approved by the DTP PMC.

Purpose

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, since 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

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

  • From Monday, 5/5, through Wednesday, 5/7: Testing 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.