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"
| 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 | + | 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 | + | *For each DTP Approved Build cycle, the PMC will determine a Candidate Build date. |
| − | *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 project lead should work with their teams to test the DTP | + | *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 | + | *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 | + | **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 | + | **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 | + | **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 | + | *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
Contents
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.