Jump to: navigation, search

Difference between revisions of "DTP Incubator Promotion Policy"

(Policy)
Line 20: Line 20:
  
 
(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):
 
(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
+
*Newsgroup and mailing list messages
**Number of bugs and enhancements reported/fixed in Bugzilla
+
*Number of bugs and enhancements reported/fixed in Bugzilla
**Number of downloads
+
*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.
 
(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.

Revision as of 15:02, 17 April 2008

Back to Main DTP Page

Status

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

[4/17/08]: Initial draft created

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.

(2) The incubator project must build and run in the current target release environment of DTP (supporting the same requirements of the current DTP release). The incubator project should be a part of the regular build process for DTP and available on the project website for download.

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

(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) Though not required, available user documentation would also help the promotion process. This could be addressed in a variety of ways including JavaDoc, help system integration, and so on.

Frequently Asked Questions (FAQ)

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 35 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 M6 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 M6. Note however that the PMC can consider promotions as late as the M7 release if the need is warranted.