Skip to main content
Jump to: navigation, search

Difference between revisions of "DTP Ganymede Milestone Sign-off Policy"

Line 1: Line 1:
 
==Status==
 
==Status==
 
'''[12/7/07]:''' This document is a '''draft''' and has not been approved by the DTP PMC.
 
'''[12/7/07]:''' This document is a '''draft''' and has not been approved by the DTP PMC.
 +
==Definitions==
 +
*'''Approved Build:''' A milestone, release candidate or release as declared by the DTP PMC.
 +
*'''Candidate Build:''' A build being tested in consideration to be declared an Approved Build.
 
==Introduction==
 
==Introduction==
As both an Eclipse project and a member of coordinated releases (Callisto, Europa, Ganymede), it is imperative that DTP milestones, release candidates (RC), and releases are of acceptable quality.
+
As both an Eclipse project and a member of coordinated releases (Callisto, Europa, Ganymede), it is imperative that DTP Approved Builds are of acceptable quality.
 
==Process==
 
==Process==
*For each DTP milestone, RC and release date, the PMC will determine a "candidate build" date on which the associated DTP build will be taken as the testing target.
+
*For each DTP Approved Build cycle, the PMC will determine a Candidate Build date.
*For each DTP milestone, RC and release date, the PMC will determine a sign-off close date and publish it to the dtp-pmc mailing list.
+
*For each DTP Approved Build cycle, the PMC will determine a sign-off close date and publish it to the [mailto:dtp-pmc@eclipse.org dtp-pmc] mailing list.
*Each DTP project lead should work with their teams to test the DTP candidate build.
+
*Each DTP project lead should work with their teams to test the DTP Candidate Build.
*By the sign-off close date, each DTP project lead will send an email to dtp-pmc expressing one of the following sign-off options:
+
*By the sign-off close date, each DTP project lead will send an email to [mailto:dtp-pmc@eclipse.org dtp-pmc] with one of the following opinions:
**Accepted: "In the project lead's best judgement, their project components are ready for the milestone/RC/release."
+
**Accepted: "In the project lead's best judgement, their project components are ready for the Approved Build."
**Accepted, with reservations: "In the project lead's best judgement, their project components are ready for the milestone/RC/release, with the following reservations." Next, a list of Bugzilla entries specific to that project, which the project lead would ideally like to see resolved, but not enough strictly to postpone the milestone/RC/release completion.
+
**Accepted, with reservations: "In the project lead's best judgement, their project components are ready for the Approved Build, with the following reservations." This is followed by a list of Bugzilla entries specific to that project, which the project lead would ideally like to see resolved, but not enough strictly to postpone the Approved Build.
**Declined: "In the project lead's best judgement, their project components are not ready for the milestone/RC/release." Next, a list of Bugzilla entries specific to that project, which the project lead believes must be resolved before milestone/RC/release completion.
+
**Declined: "In the project lead's best judgement, their project components are not ready for the Approved Build." This is followed by a list of Bugzilla entries specific to that project, which the project lead believes must be resolved before declaration of the Approved Build.
*Based on the reports provided, the PMC will decide whether to declare the milestone/RC/release complete.
+
*Based on the reports provided, the PMC will decide whether to declare the Approved Build.
 
*On an exception basis, this information will be provided to the current coordinated release via the associated mailing list. Exceptions include:
 
*On an exception basis, this information will be provided to the current coordinated release via the associated mailing list. Exceptions include:
 
**Reservations expressed by project leads.
 
**Reservations expressed by project leads.
 
**Absence of reports from project leads.
 
**Absence of reports from project leads.
 
**PMC override of project lead declines.
 
**PMC override of project lead declines.

Revision as of 14:37, 7 December 2007

Status

[12/7/07]: This document is a draft and has not been approved by the DTP PMC.

Definitions

  • Approved Build: A milestone, release candidate or release as declared by the DTP PMC.
  • Candidate Build: A build being tested in consideration to be declared an Approved Build.

Introduction

As both an Eclipse project and a member of coordinated releases (Callisto, Europa, Ganymede), it is imperative that DTP Approved Builds are of acceptable quality.

Process

  • For each DTP Approved Build cycle, the PMC will determine a Candidate Build date.
  • For each DTP Approved Build cycle, the PMC will determine a sign-off close date and publish it to the dtp-pmc mailing list.
  • Each DTP project lead should work with their teams to test the DTP Candidate Build.
  • By the sign-off close date, each DTP project lead will send an email to dtp-pmc with one of the following opinions:
    • Accepted: "In the project lead's best judgement, their project components are ready for the Approved Build."
    • Accepted, with reservations: "In the project lead's best judgement, their project components are ready for the Approved Build, with the following reservations." This is followed by a list of Bugzilla entries specific to that project, which the project lead would ideally like to see resolved, but not enough strictly to postpone the Approved Build.
    • Declined: "In the project lead's best judgement, their project components are not ready for the Approved Build." This is followed by a list of Bugzilla entries specific to that project, which the project lead believes must be resolved before declaration of the Approved Build.
  • Based on the reports provided, the PMC will decide whether to declare the Approved Build.
  • On an exception basis, this information will be provided to the current coordinated release via the associated mailing list. Exceptions include:
    • Reservations expressed by project leads.
    • Absence of reports from project leads.
    • PMC override of project lead declines.

Back to the top