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

Revision as of 14:52, 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 declared by the DTP PMC.
• Candidate Build: A build being tested in consideration to be declared an Approved Build.
• Sign-off: The act of reporting on a project's readiness for 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. Further, in the interest of transparent and open communication encouraged by the Eclipse community, we should be clear about the perceived quality of each DTP Approved Build. Finally, we recognize that determining the quality level of software components involves many inputs and ultimately a judgement call. Thus we do not specify exactly how the determination will be made: this is up to individual project leads to decide what works best in their case. The process below is designed to meet these aims.

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 strictly severe enough 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.