Skip to main content
Jump to: navigation, search

Modeling Project Organization

Revision as of 12:14, 19 February 2007 by (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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. Only the committers for that component will have access to that CVS module. 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. As such, 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, using the same standard Eclipse rules used when voting for a new committer to a subproject, to approve the new component along with its initial committers. We 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. Each subproject will synchronize the common builds and releases for its components to provide a cohesive build/release stream for all downstream consumers.

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.

Back to the top