DTP Incubator Promotion Policy

← Back to Main DTP Page

Status

[4/15/08]: Policy discussed during PMC meeting

[4/17/08]: Initial draft created

[4/22/08]: Edited per PMC comments

[11/11/08]: Edited with clarification discussed with PMC, based on similar policy adopted in WTP

Introduction

This document specifies the policy for migrating component plug-in projects from the DTP Incubator into one of the sub-projects of the main DTP codeline. All criteria listed in the policy should all be considered, but the degree to which each is required should be taken on a case-by-case basis.

Note that this policy exists for projects already in the DTP Incubator. There is a separate process for moving new projects into the incubator.

Policy

When the committers involved in an incubated project feel they are ready to be considered for promotion into one of the sub-projects of the main DTP codeline, they should schedule a promotion review meeting with the PMC by publicly declaring that they are ready for such a review. They can declare readiness by creating a Bugzilla entry for the review and then sending an e-mail to the dtp-pmc mailing list.

Incubated projects seeking promotion must meet the following standards:

(1) Regular committers must be working on the incubator project code on an active basis. Committers in this case might be new and only working on the incubator project or might include committers from other DTP sub-projects or elsewhere in the Eclipse community. However, if there are no active committers doing the work, it's not really considered a "live" component and therefore not eligible for promotion. For a description of what a committer at Eclipse is expected to do, see [Committer Guidelines].

(2) The incubator project must build and run in the current target release environment of DTP. This implies the code will be upgraded to the current DTP supported level and will track DTP weekly, i.e. I-builds succeed. The incubator project should be integrated into the DTP build infrastructure and the JUnit tests should run and pass. Both update sites and "all-in-one-zip" download packaging on the project website must be supported.

(3) The incubator project must be supporting an active community and doing things the Eclipse Way. This support can be measured in a variety of ways, including (but not limited to):

• Newsgroup and mailing list messages
• Number of bugs and enhancements reported/fixed in Bugzilla
• Number of downloads

(4) Committers working on the incubator project must be actively pursuing code quality. The pursuit of quality can be demonstrated via a suite of JUnit tests, design documents, test process (non-automated) documents, and so on. Specifically,

• The code should be of good quality and all proposed API should have Javadoc
• There should be a suite of JUnit tests that provide adequate coverage (where possible).

(5) Committers must be actively pursuing the functional completeness of the component. Does your incubator project have enough functionality to be useful to the community? Does it meet the needs of the community?

(6) The target release for promotion of the incubator project must be ready to receive changes. Component owners should get agreement from PMC about when an acceptable time window is for acceptance into a release. For a Core project, must be early in the cycle to reduce the impact on downstream consumers. For Enablement, it might be later in the cycle.

(7) All contribution questionnaires must be on file and IP status must be integrated with the DTP IP log, along with committer and contribution records.

(8) Though not required, available user documentation would also help the promotion process. This could be addressed in a variety of ways including simple to follow tutorials, JavaDoc, help system integration, and so on.

When a promotion review meeting is held, the PMC must hold a majority vote to approve the component for promotion. For incubator component being promoted to a Core project, a vote from that project's committers should pass favorably as well. If a majority of PMC votes is not reached, the component committers can resubmit their project for promotion again after they have addressed PMC and community concerns.

Frequently Asked Questions (FAQ)

Q: How do I get a project into the DTP incubator?

A: This is handled in a separate policy. Please see the DTP Incubator Policy Page for details.

Q: How do I know if I'm ready for my incubator project to be considered for promotion?

A: When you feel your project is ready for promotion, for each of the criteria listed above, rank your project's readiness on a scale from 1 to 10. If when you're done with the ranking you have a total of 45 or higher, drop a note to the PMC list and request a review. This is obviously a subjective ranking, but it can provide a useful guideline for determining promotion readiness.

Q: Where will my incubator project be promoted to if the promotion is approved?

A: In most cases, projects will fit best in the Enablement sub-project, though it could be promoted to any of the existing sub-projects. The sub-project lead(s) can voice their opinions on the incubator project's readiness at the promotion review. There may be cases were a particular incubator project may warrant creation of a new sub-project. However, that will most likely be a rare occurrence and would require the usual steps for creation of a new Eclipse sub-project within DTP.

Q: What is the best time to consider promoting my incubator project?

A: In most cases, we would consider promoting an incubator project during a major release. Eclipse policy prohibits adding new features or plug-ins during maintenance releases, so the window for a major release is the best option. In addition, the feature freeze milestone is typically the M7 milestone, so any new features such as those represented by an incubator project would need to be delivered and part of the main DTP build cycle by the API freeze milestone (typically M6). Note however that the PMC can consider promotions as late as the feature freeze (typically M7) milestone if the need is warranted.