Modeling Project Organization
Revision as of 13:35, 21 October 2007 by Codeslave.ca.ibm.com (Talk | contribs) (refactor, add sections & whitespace for digestibility)
- Each of the Modeling project's subprojects is managed as a collection of one or more separate components, much like a top-level project comprises separate subprojects.
- Each component will have a component lead and a collection of additional committers.
- There will be a CVS module for all the source code of that component, and a second module for that component's releng needs.
- Only the committers for that component will have access to those 2 CVS modules.
- When a component wants to add new committers, only the committers for that component are involved in the vote and only their collective vote is considered relevant.
Components as Siblings
- Each subproject will be a collection of relatively independent components, each with autonomy to control their own component as they see fit (within the constraints imposed by the foundation).
- When a new component is to be added to a subproject, all the committers of the existing components will review the proposal and will vote to approve the new component along with its initial committers using the same standard Eclipse voting rules used when voting for a new committer to a subproject.
Newsgroups and Mailing Lists
- Each component will typically use a common newsgroup and mailing list for each subproject, but, if the need arises, components may have their own newsgroup or mailing list.
Builds and Scheduling
- Each subproject will synchronize the common builds and releases for its components to provide a cohesive build/release stream for all downstream consumers.
EMFT as EMF Incubator
- The EMFT project will be treated as if it were part of the EMF project with regard to the above rules, which is really just saying that all EMFT and EMF committers will vote when adding new components to either subproject.