Difference between revisions of "DTP Incubator Promotion Policy"

From Eclipsepedia

Jump to: navigation, search
(Status)
Line 3: Line 3:
 
[4/15/08]: Policy discussed during PMC meeting
 
[4/15/08]: Policy discussed during PMC meeting
  
[4/16/08]: Initial draft created
+
[4/17/08]: Initial draft created
  
 
==Introduction==
 
==Introduction==
Line 15: Line 15:
 
Incubated projects seeking promotion must meet the following standards:
 
Incubated projects seeking promotion must meet the following standards:
  
(1) Needs regular committers working on this code on an active basis - might be new committers or existing ones - but if there's nobody doing the work, it's not a live component. They need to step in as committers and move the component forward.
+
(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) Build with the current target release environment of DTP (supporting the same requirements of the current DTP release). Available build as an "incubator" project zip as part of Xiaoying's automated build process.
+
(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) Must be supporting an active community and doing things the Eclipse Way (can measure via comments on newsgroup or mailing lists, reporting bugs/enhancements, downloads, and so on).
+
(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) Must be actively pursuing code quality (demonstrated through something like unit tests, non-automated tests, 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.
  
(5) Must be actively pursuing the functional completeness of the component (does it have enough functionality to be useful to the community).
+
(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) Target release must be ready to receive changes (for example, must be done before the RC cycle, i.e. at latest M6 or M7). 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. For Enablement, might be later in the cycle. API Freeze vs. Feature Freeze? Level of impact for downstream consumers.
+
(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) User documentation support would be great - JavaDoc, help system integration, and so on.
+
(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.
  
==ROUGH (To be deleted)==
+
==Frequently Asked Questions (FAQ)==
*Promoting incubator projects -- different to promote a component than a project
+
 
**A bit premature for Ganymede, but have two maintenance releases coming up in the fall and winter, though we can't add new features/components to maintenance releases -- or next coordinated release in 2009
+
Q: How do I know if I'm ready for my incubator project to be considered for promotion?
**Don't want to promote too quickly to set a precedent
+
 
**Pick and choose what bits and pieces of existing procedure for project incubation as applies to components
+
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.
**Broader process issues -- what does it take to graduate from incubation to DTP? Once we get a policy in place, if Eclipse comes up with a plan down the line, we can contribute to it.
+
 
**Get this incubator project into the build specially - calling it "incubator" -- get it into Xiaoying's process
+
Q: Where will my incubator project be promoted to if the promotion is approved?
**Become committers, get builds working, and demonstrate to the PMC that the tests are passing, code works, community is interested -- don't want to seem arbitrary or not coordinated. These criteria should all be considered, but should also be taken on a case-by-case basis.
+
 
***(1) Needs regular committers working on this code on an active basis - might be new committers or existing ones - but if there's nobody doing the work, it's not a live component. They need to step in as committers and move the component forward.
+
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.
***(2) Build with the current target release environment of DTP (supporting the same requirements of the current DTP release). Available build as an "incubator" project zip as part of Xiaoying's automated build process.
+
 
***(3) Must be supporting an active community and doing things the Eclipse Way (can measure via comments on newsgroup or mailing lists, reporting bugs/enhancements, downloads, and so on).
+
Q: What is the best time to consider promoting my incubator project?
***(4) Must be actively pursuing code quality (demonstrated through something like unit tests, non-automated tests, documents, and so on).
+
 
***(5) Must be actively pursuing the functional completeness of the component (does it have enough functionality to be useful to the community).
+
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.  
***(6) Target release must be ready to receive changes (for example, must be done before the RC cycle, i.e. at latest M6 or M7). 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. For Enablement, might be later in the cycle. API Freeze vs. Feature Freeze? Level of impact for downstream consumers.
+
***(7) User documentation support would be great - JavaDoc, help system integration, and so on.
+
**When they think they are ready, we have a mini creation review and post their intention for community feedback. Use Bugzilla to register this. A week for community feedback and then the review. PMC vote should be by a majority (3/4)
+
**Aside from the EMF-Ecore driver, we need to agree on a set of criteria for graduating components. Then apply them to the EMF-Ecore case and see how things fall out.
+
  
 
[[Category:Data Tools Platform]]
 
[[Category:Data Tools Platform]]

Revision as of 15:02, 17 April 2008

Back to Main DTP Page

Contents

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.