Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
DTP PMC Meeting, April 15, 2008
← Back to DTP PMC Meeting Page
Contents
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).
- (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).
- When they think they are ready, we have a mini creation review and post their intention for community feedback. Use Bugzilla to register this.
- 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