Jump to: navigation, search

Difference between revisions of "DTP Ganymede Rampdown Policy"

(DTP 1.6RC0(M7): May 5 (Monday))
Line 18: Line 18:
  
 
===DTP 1.6RC0(M7): May 5 (Monday)===
 
===DTP 1.6RC0(M7): May 5 (Monday)===
*From Monday, 5/5, through Wednesday, 5/7: Testing Pass
+
*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 http://wiki.eclipse.org/DTP_Build_Transition) 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.
 
*From Thursday, 5/8, through Friday, 5/16: Testing & Fix Pass: Standard DTP policies apply.
  

Revision as of 11:35, 30 April 2008

Back to DTP Main Page


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

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 http://wiki.eclipse.org/DTP_Build_Transition) 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.