This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
wiki:vswitchperf_governance_model [2015/02/02 16:18] Maryam Tahhan |
wiki:vswitchperf_governance_model [2015/02/18 18:05] (current) Maryam Tahhan |
||
---|---|---|---|
Line 4: | Line 4: | ||
===Roles:=== | ===Roles:=== | ||
- | + | From [[https://www.opnfv.org/developers/technical-project-governance/tsc-charter|TSC-Charter]] | |
- | * __Contributor:__ Any OPNFV member can be a contributor to this project. Could be a mailing list lurker who asks valuable questions or provides new features/bug fixes for code or documentation as patches. Valuable contributors could and should be invited to become committers. | + | * __Contributor:__ Most Contributors work with their Committer and their component’s sub-community. They contribute code or other artifacts, but do not have the right to commit to the code base. A Contributor may be promoted to a Committer by the projects’ Committers. |
- | * __Committer:__ Someone who is committed to the project. Committers will have direct access to the code repository and will be able to review/+1 others patches in Gerrit. | + | * __Committer:__ A person with rights to commit code or artifacts to the source code management system. The Committers will be the decision makers on design, code, packaging, and patches for their project. They must responsibly participate in the consensus decisions of the project. Committer rights are earned via code contribution and community trust. Committers select and vote for new Committers. |
* __Reviewer:__ Committer. | * __Reviewer:__ Committer. | ||
* __Maintainer:__ A gatekeeper to the repository, so someone who will ensure that a patch has received the appropriate +1’s and is able to give a +2 in Gerrit. The maintainer is an admin role that provides a +2, but is not a decision maker/benign dictator per se. The Maintainer enforces the agreed process. We will need to assign an overall maintainer. | * __Maintainer:__ A gatekeeper to the repository, so someone who will ensure that a patch has received the appropriate +1’s and is able to give a +2 in Gerrit. The maintainer is an admin role that provides a +2, but is not a decision maker/benign dictator per se. The Maintainer enforces the agreed process. We will need to assign an overall maintainer. | ||
Line 37: | Line 37: | ||
Each patch should be related to a particular JIRA issue/feature. | Each patch should be related to a particular JIRA issue/feature. | ||
- | Each submitted patch will go through a Gerrit review. To move to the next stage, the patch MUST receive two +1s in Gerrit (Under Code-Review i.e. +1 Looks good to me, but someone else must approve) from at least two committers of two different companies. | + | Each submitted patch will go through a Gerrit review. To move to the next stage, the patch MUST receive a +1 in Gerrit (Under Code-Review i.e. +1 Looks good to me, but someone else must approve) from at a committer from a different company. |
- | Once a patch has received the two required +1s, the patch needs to be +2’d (Under Code-Review i.e. Looks good to me, approved) by the maintainer and pushed to the repo. | + | Once a patch has received the required +1, the patch should be +2’d (Under Code-Review i.e. Looks good to me, approved) by the maintainer and pushed to the repo. |
In the case of deadlock the same decision making process as specified above will be followed. | In the case of deadlock the same decision making process as specified above will be followed. | ||