Jump to: navigation, search

Difference between revisions of "DTP Incubator Promotion Policy"

m (Status)
 
(19 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
==Status==
 
==Status==
 
[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
 +
 
 +
[4/22/08]: Edited per PMC comments
 +
 
 +
[11/11/08]: Edited with clarification discussed with PMC, based on similar policy adopted in WTP
  
 
==Introduction==
 
==Introduction==
Line 14: Line 19:
 
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. For a description of what a committer at Eclipse is expected to do, see [[http://www.eclipse.org/legal/committerguidelines.php 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?
  
(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.
+
A: This is handled in a separate policy. Please see the [[ DTP Incubator | DTP Incubator Policy Page]] for details.
  
(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: How do I know if I'm ready for my incubator project to be considered for promotion?
  
(4) Must be actively pursuing code quality (demonstrated through something like unit tests, non-automated tests, documents, and so on).
+
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.
  
(5) Must be actively pursuing the functional completeness of the component (does it have enough functionality to be useful to the community).
+
Q: Where will my incubator project be promoted to if the promotion is approved?
  
(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.
+
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.
  
(7) User documentation support would be great - JavaDoc, help system integration, and so on.
+
Q: What is the best time to consider promoting my incubator project?
  
==ROUGH (To be deleted)
+
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.  
*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
+
**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
+
**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
+
**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.
+
***(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).
+
***(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).
+
***(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]]

Latest revision as of 20:28, 11 November 2008

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.