Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

Line 1: Line 1:
 +
{{Back To|name=DTP Main Page|href=Data Tools Platform Project}}
 
==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.

Revision as of 15:13, 7 December 2007

Back to DTP Main Page

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

The sign-off is similar to a CEO of a public company attesting to the company's financial statements. That is, to the best of our knowledge, we make assertions about the quality of DTP Candidate Builds. Naturally, it might later transpire that certain problems did exist. We do not expect perfection, but simply the best judgment call possible from the DTP team at a given point in time with a given collection of facts. While no process can guarantee perfection, the absence of a process attempting to check falls short of the best faith efforts expected by the Eclipse community.

Process

  • For each DTP Approved Build cycle, the PMC will determine a Candidate Build 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 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 judgment, their project components are ready for the Approved Build."
    • Accepted, with reservations: "In the project lead's best judgment, 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 judgment, 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