Difference between revisions of "DTP Ganymede Rampdown Policy"

(New page: {{Back To|name=DTP Main Page|href=Data Tools Platform Project}} ==Status== Note that this document will be updated as necessary during the DTP 1.6 ("Ganymede") release. ==Purpose== This ...)

Note that this document will be updated as necessary during the DTP 1.6 ("Ganymede") release.

==Purpose==

==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.

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

==Rampdown Cycle Phases==

Line 18:

Line 16:

==Rampdown Cycles==

==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 [http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=29&year=2008&hour=5&min=0&sec=0&p1=237 5am (Shanghai time)].

**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 Wednesday, 5/21, through Friday, 5/23: Testing & Fix Pass: All bugs must approved by project lead who must notify the [mailto:dtp-pmc@eclipse.org 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 [mailto:dtp-pmc@eclipse.org 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.

−

'''Note:''' Builds and promotion decisions occur on the days noted, at 10EST.

+

===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 [mailto:dtp-pmc@eclipse.org 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.

−

'''[8/31/07]: Cycles TBD'''

+

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

**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.

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

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.

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).

DTP 1.6RC1: May 19 (Monday)

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.