Difference between revisions of "DTP PMC Meeting, April 15, 2008"

Revision as of 14:48, 15 April 2008

← Back to DTP PMC Meeting Page

Attendees

• Brian Fitzpatrick
• Sheila Sholars
• Linda Chan
• John Graham

Regrets

Agenda

• Apologies in advance if I have to bounce out briefly
• Talk about some SY staffing issues and what's being done
• Talk about how to promote incubator projects
• Open discussion

Minutes

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

Action Items

• Create Wiki page for Incubator Enablement Component promotion