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.
Difference between revisions of "DTP Ganymede Milestone Sign-off Policy"
| (16 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Back To|name=DTP Main Page|href=Data Tools Platform Project}} | ||
==Status== | ==Status== | ||
| − | '''[12/ | + | '''OBSOLETE''' |
| + | |||
| + | '''[3/5/08]:''' In the 3/4/08 DTP PMC meeting, the decision was made to repeal this process based on (lack of) community interest in support it. | ||
| + | |||
| + | '''[12/17/07]:''' This document has been reviewed and approved by the DTP PMC. This policy will start with the '''DTP 1.6M5 cycle'''. | ||
| + | ==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. | ||
| + | *'''DTP Framework Project:''' The DTP Connectivity, Model Base and SQL Development Tools projects. | ||
| + | *'''Sign-off:''' The act of reporting on a project's readiness for an Approved Build. | ||
==Introduction== | ==Introduction== | ||
| − | As both an Eclipse project and a member of coordinated releases (Callisto, Europa, Ganymede), it is imperative that DTP | + | 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== | ==Process== | ||
| − | *For each DTP | + | *For each DTP Approved Build cycle, the PMC will determine a Candidate Build date and publish it to the [mailto:dtp-pmc@eclipse.org dtp-pmc] mailing list. |
| − | *For each DTP | + | *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 | + | *Each DTP Framework Project lead should work with their teams to test the DTP Candidate Build. |
| − | *By the sign-off close date, each DTP | + | *By the sign-off close date, each DTP Framework 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 | + | **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 | + | **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 | + | **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 DTP Framework Project leads. | ||
| + | **Absence of reports from DTP Framework Project leads. | ||
| + | **PMC override of DTP Framework Project lead declines. | ||
Latest revision as of 16:12, 5 March 2008
Contents
Status
OBSOLETE
[3/5/08]: In the 3/4/08 DTP PMC meeting, the decision was made to repeal this process based on (lack of) community interest in support it.
[12/17/07]: This document has been reviewed and approved by the DTP PMC. This policy will start with the DTP 1.6M5 cycle.
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.
- DTP Framework Project: The DTP Connectivity, Model Base and SQL Development Tools projects.
- 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 Framework Project lead should work with their teams to test the DTP Candidate Build.
- By the sign-off close date, each DTP Framework 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 DTP Framework Project leads.
- Absence of reports from DTP Framework Project leads.
- PMC override of DTP Framework Project lead declines.