... | ... | @@ -60,16 +60,16 @@ In the unlikely event that any member of the PMC becomes disruptive to the proce |
|
|
|
|
|
All PMC Projects are operated as meritocracies -- the more you contribute, and the higher the quality of your contribution, the more you can do.
|
|
|
|
|
|
Each Project must identify, and make available on its web site, the requirements and prioritizations it is working against in the current release cycle. In addition, each Project must post a release plan showing the date and content of the next major release, including any major milestones, and must keep this plan up to date.
|
|
|
Each PMC Project must identify, and make available on its web site, the requirements and prioritizations it is working against in the current release cycle. In addition, each PMC Project must post a release plan showing the date and content of the next major release, including any major milestones, and must keep this plan up to date.
|
|
|
|
|
|
When a new Project is created, the PMC nominates a Project Lead to act as the technical leader, and nominates the initial set of Project Committers for the Project. The Project Lead is accountable to the PMC for the success of their Project.
|
|
|
The Committers of a Project or component decide which changes may be committed to the master code base of a Project or component respectively. The PMC defines the decision process, but that process must include the ability for Committers to veto the change. The decision process employed may change with the phase of development. Common decision processes include:
|
|
|
When a new PMC Project is created, the PMC nominates a PMC Project Lead to act as the technical leader, and nominates the initial set of Project Committers for the Project. The PMC Project Lead is accountable to the PMC for the success of their PMC Project.
|
|
|
The Committers of a PMC Project or component decide which changes may be committed to the master code base of a PMC Project or component respectively. The PMC defines the decision process, but that process must include the ability for Committers to veto the change. The decision process employed may change with the phase of development. Common decision processes include:
|
|
|
* *Retroactive *- changes are proactively made by Committers but can be vetoed by a single Committer.
|
|
|
* *Proactive *- for efficiency, some code changes from some contributors (e.g. feature additions, bug fixes) may be approved in advance, or approved in principle based on an outline of the work, in which case they may be committed first and changed as needed, with conflicts resolved by majority vote of the Committers of the Project or component, as applicable.
|
|
|
* *Three Positive* - No code is committed without a vote; three +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to approve a code change.
|
|
|
Vetoes must be followed by an explanation for the veto within 24 hours or the veto becomes invalid. All votes are conducted via the developer mailing list associated with the Project or component. Special rules may be established by the PMC for Projects or components with fewer than three Committers.
|
|
|
Vetoes must be followed by an explanation for the veto within 24 hours or the veto becomes invalid. All votes are conducted via the developer mailing list associated with the PMC Project or component. Special rules may be established by the PMC for PMC Projects or components with fewer than three Committers.
|
|
|
|
|
|
The master copy of the code base must reside on the Project web site where it is accessible to all users, developers and committers. Committers must check their changes and new work into the master code base as promptly as possible (subject to any check-in voting rules that may be in effect) in order to foster collaboration among widely distributed groups and so that the latest work is always available to everyone.
|
|
|
The master copy of the code base must reside on the PMC Project web site where it is accessible to all users, developers and committers. Committers must check their changes and new work into the master code base as promptly as possible (subject to any check-in voting rules that may be in effect) in order to foster collaboration among widely distributed groups and so that the latest work is always available to everyone.
|
|
|
|
|
|
The PMC is responsible for establishing a release engineering and build process to ensure that builds can be reliably produced on a regular and frequent basis from the master code base, and made available for download from the Project web site. Builds in this context are intended to include not only code but also reports, documentation, and courseware.
|
|
|
|
... | ... | @@ -77,15 +77,15 @@ Each Project is responsible for establishing test plans and the level of testing |
|
|
|
|
|
All development technical discussions are conducted using the development mailing lists. If discussions are held offline, then a summary must be posted to the mailing list to keep the other committers, and any other interested parties,
|
|
|
Given the fluid nature of PMC Projects, organizational changes are possible. In particular, there may be a need to:
|
|
|
* divide a Project into components
|
|
|
* divide a Project into two or more independent Projects
|
|
|
* merge two or more Projects into a single Project.
|
|
|
* divide a PMC Project into components
|
|
|
* divide a PMC Project into two or more independent PMC Projects
|
|
|
* merge two or more PMC Projects into a single PMC Project.
|
|
|
|
|
|
In each case, the initiative for the change may come either from within the Project, or from the PMC; but the PMC must approve any change.
|
|
|
|
|
|
If a Project wishes to divide into components, commit privileges are normally granted at the component level. Components are established and discontinued by the PMC. When the PMC creates a component, it appoints a Component Lead to act as the technical leader and names the initial set of Committers for the component. The Component Lead is designated as a Committer for the Project, and represents the Component in discussions. Component committers do not participate in votes at the level of the Project as a whole, unless they are also the Component Lead.
|
|
|
If a PMC Project wishes to divide into components, commit privileges are normally granted at the component level. Components are established and discontinued by the PMC. When the PMC creates a component, it appoints a Component Lead to act as the technical leader and names the initial set of Committers for the component. The Component Lead is designated as a Committer for the PMC Project, and represents the Component in discussions. Component committers do not participate in votes at the level of the PMC Project as a whole, unless they are also the Component Lead.
|
|
|
|
|
|
In cases where new Projects are being created, either by splitting or by merging, the usual procedures for the establishment of a new Project are followed. In particular, Contributors will not necessarily have the same rights after an organizational change that they enjoyed in the previous structure.
|
|
|
In cases where new PMC Projects are being created, either by splitting or by merging, the usual procedures for the establishment of a new PMC Project are followed. In particular, Contributors will not necessarily have the same rights after an organizational change that they enjoyed in the previous structure.
|
|
|
|
|
|
### PMC Project Roles
|
|
|
|
... | ... | |