Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Trace Compass/committer"
(→What is a committer?) |
(→Vouchers) |
||
| Line 22: | Line 22: | ||
=Vouchers= | =Vouchers= | ||
| − | You will need one or more vouchers. The | + | You will need one or more vouchers. The other committers are allowed to vouch. Each voucher must already have commit access and be confident enough in you to be associated with your check-ins. Your vouchers are responsible for your bustages in the unfortunate event that you break things and leave. They are responsible for making sure you know and follow the rules in general, act promptly to fix regressions, are aware of and respect tree closures, etc. The vouchers' responsibility extends for three months after you are granted source code commit access. If you've lived in the tree without significant issues for three months, we assume you're ready to stand on your own. If somehow there are persistent problems during the first three months, the vouchers have the authority to request revocation of your access during this period. Vouching is a big responsibility, so people will make this commitment only after due consideration. A voucher who helps people who aren't prepared get access to the source tree will find that his or her own credibility suffers as well. |
=Revoking Commit Access= | =Revoking Commit Access= | ||
Revision as of 12:30, 8 July 2016
Contents
What is a Committer?
Technically, a committer is someone who has write access to the Trace Compass Git repository and can submit patches with only one co-committer's approval. A committer has the right to vote on patches from others, and verify patch functionality, thus vouching for the quality of someone else's work.
This privilege is granted with some expectation of responsibility: committers are people who care about the Trace Compass projects and want to help them meet their goals. A committer is not just someone who can make changes, but someone who has demonstrated his or her ability to collaborate with the team, get the most knowledgeable people to review code, contribute high-quality code, and follow through to fix issues (in code or tests).
Requirements to be a committer
In a nutshell, contribute 10-20 non-trivial patches and get at least three different people to review them (you'll need three people to support you). Then ask someone to nominate you. You're basically demonstrating your
- commitment to the project (10+ good patches requires a lot of your valuable time),
- ability to collaborate with the team,
- understanding of how the team works (policies, processes for testing and code review, OWNERS files, etc),
- understanding of the projects' code base and coding style, and
- ability to write good code (last but certainly not least)
That's it! There is no further action you need to take on your part. The committers will get back to you once they make a decision.
In the worst case, this can drag out for two weeks. Keep writing patches! Even in the rare cases where a nomination fails, the objection is usually something easy to address like "more patches" or "not enough people are familiar with this person's work."
Once you get approval from the existing committers, we'll send you instructions for write access to Git. This lowered the requirement from having two committers approving your patches.
Vouchers
You will need one or more vouchers. The other committers are allowed to vouch. Each voucher must already have commit access and be confident enough in you to be associated with your check-ins. Your vouchers are responsible for your bustages in the unfortunate event that you break things and leave. They are responsible for making sure you know and follow the rules in general, act promptly to fix regressions, are aware of and respect tree closures, etc. The vouchers' responsibility extends for three months after you are granted source code commit access. If you've lived in the tree without significant issues for three months, we assume you're ready to stand on your own. If somehow there are persistent problems during the first three months, the vouchers have the authority to request revocation of your access during this period. Vouching is a big responsibility, so people will make this commitment only after due consideration. A voucher who helps people who aren't prepared get access to the source tree will find that his or her own credibility suffers as well.
Revoking Commit Access
If someone consistently causes difficulties with these source repositories due to poor behavior or other serious problems then commit access may be revoked. We have no precise process for this as it has been a rare or nonexistent problem to date. The process for this is for one or more committers with concerns the project leads. Do not do so carelessly, or based on passing irritation or without a sense that you are not alone in your concerns. The leads will investigate or cause an investigation to occur, privately at first and perhaps completely privately.
Dormant Accounts
If your account in a particular SCM is inactive for more than 6 months, it may be deactivated. However, the knowledge that you have achieved a particular level of access is retained. Therefore, getting your account reactivated is a simple matter of filing a bug asking IT to turn it back on. Such bugs should be dealt with extremely quickly.
References
https://www.chromium.org/getting-involved/become-a-committer
https://www.mozilla.org/en-US/about/governance/policies/commit/