Gerrit/权限方针
 | This page documents an official Wikimedia development policy. There is no current mechanism to make changes, as the TechCom RFC process is defunct. |
| Development policies |
|---|
| See also |
| 开发指引 |
权利和义务
在大多数维基媒体Gerrit仓库设置中，如果一名用户给出了“+2”的代码审查结果，Jenkins便会在运行测试后自动合并这一更改。
所以给出代码审查+2的权限只赋予特定Gerrit用户组。
通常，每个代码仓库都有以仓库命名的Gerrit用户组，且在该仓库具有权限。
同时，有些Gerrit组在多个代码仓库都有权限。
尤其是mediawiki组在MediaWiki内核和所有扩展与皮肤都有权限，外加其他一些与MediaWiki相关的仓库。
Gerrt组可以继承LDAP组的成员。
绝大多数WMF雇员都属于LDAP的wmf组，从而自动拥有mediawiki组的成员资格。
Gerrit管理员可以向Gerrit组中添加或移除成员。
Merging a change to the MediaWiki core or an extension deployed by Wikimedia is a big deal. The change will be automatically deployed to the Beta叢集, a virtualized staging environment, as soon as it's been merged in Gerrit. It will also be automatically picked up in the next MediaWiki core deployment window (see Deployments) unless it is reverted before the release branch is cut.
您的合并操作可能导致维基百科或其他站点崩溃。 也可能引入安全漏洞，而让攻击者删除、破坏数据，或访问私人信息。 更常见的情况是，如果代码没有测试、测试实现得很差或交互很差，则可能会导致technical debt增加。 You should carefully read this document and all relevant policies before using +2.
+2 is a strong expression of trust, and trust is maintained through good judgement and careful action.
In code review, design discussions, and bug comments, those with +2 power have a special responsibility to see from others' points of view.
Merging without review
Merging code without review is bad for code quality and bad for morale. The point of +2 rights is to separate development and code review. The purpose of merging a change in Gerrit is to tell the world that "Yes, I've ensured that this change follows MediaWiki conventions, good engineering practices and is sensible." (Cf. "Code Reviews: Just Do It" by Jeff Atwood.) Inline comments can be used to indicate issues with the code that should be addressed before it is merged.
Merging your own code without approval from a reviewer may be grounds for revocation of privileges.
This is not necessarily the same as giving +2 to a Gerrit change owned by yourself. For example:
- If a change receives +2 from a reviewer, but the Jenkins build fails, the owner might need to give it +2 to restart the build job.
- Reverts can generally be self-merged, as long as the commit it is reverting was recent. You are reverting to a version which was presumably reviewed at the time.
- In deployment branches and the Puppet repository, changes are merged by the person doing the deployment, who is often also the author. In these cases, code review is typically indicated by giving +1 to the change.
- A commit in Gerrit may have two authors: an owner, and a reviewer who uploads an amendment. Typically, the owner and reviewer each review the other's work. As long as all the changes have been reviewed and approved, the commit may be merged.
Very few changes are trivial enough to self-merge. Self-merging is tolerated in some cases like trivial documentation changes or projects with only one maintainer.
For extensions (and other projects) not deployed to the Wikimedia cluster, the code review policy is up to the maintainer or author of the extension. Some non-Wikimedia extensions follow Wikimedia's policy of prohibiting self-merges, but there is no requirement of that. If you are the only person writing the extension and have nobody to review your change, or if the extension is abandoned, it is acceptable to self-merge your changes.
If you're working as part of a team, review by members of your team are not only permitted, but strongly encouraged. Having peers review your code on an ongoing basis is a great way to keep momentum of development going, and ensure that your reviewers are familiar with what you're doing.
When you're doing intra-team review, be especially sensitive about blind spots, cognitive biases, and the need to get buy-in for large changes outside the group of people you're working in. Most open source projects, including MediaWiki, are full of abandoned efforts to create fancy new abstraction layers, skinning systems, testing frameworks, etc. Consider the impact of your changes on the ecosystem as a whole, and engage in conversations through requests for comment, wikitech-l, IRC and other venues. Shared ownership of code (to a greater or lesser degree) helps to ensure that what you're doing has lasting long term value.
Must read for code reviewers
- Code review guide
- Security for developers
- 手册:代码编写约定 - and subpages
- Manual:单元测试 - and related pages
- 本地化
- Database optimization - keep this in mind when making schema changes (which should be implemented following this process)
- 手册:如何调试
申请Gerrit权限
如需申请加入mediawiki组，请在Phabricator的MediaWiki-Gerrit-Group-Requests项目下创建一个task。
然后发一封电子邮件到wikitech-l邮件列表。
To request membership in another group, create a new task under the Gerrit-Privilege-Requests project in Phabricator.
无论您是哪种情况，都需要在task中注明：
- Gerrit用户名
- 您需要哪个（些）仓库的权限
- reasoning, including links to patches written and reviewed
Developers commenting on a privilege request should consider whether the applicant has contributed high quality patches, has exercised +1 rights well, and has demonstrated competence. Negative comments should be written with tact, they should not be overly strident.
If there is a consensus of trusted developers on the Phabricator task, any of the Gerrit administrators can resolve the request. The task must remain open for at least a week, to allow interested developers to comment. Additional time should be allowed if the request is open during travel or holiday periods.
If there is no consensus on a request in Phabricator, it may be referred to TechCom for adjudication.
Previously, some extension maintainers were given ownership rights on the relevant project in Gerrit, so that they could add new group members without making a request in Phabricator. This model should not be used for new extensions. Gerrit administrators should not grant repository ownership to ordinary developers. Before an extension is deployed to the Wikimedia cluster for the first time, the rights should be audited, and legacy ownership privileges should be downgraded to +2 access.
Expedited process for trusted organisations
Gerrit administrators may immediately act on requests from the following trusted organisations for the granting and revocation of membership in their managed groups, specifically:
| Organisation | Managed groups |
|---|---|
| Wikimedia Deutschland | wmde, wmde-mediawiki
|
| ShoutWiki | ShoutWiki, Brickimedia
|
| Hallo Welt! | bluespice
|
| WikiTeq | WikiTeq
|
It is not necessary to file a Phabricator task or demonstrate consensus.
This facility is intended to allow these organisations to rapidly on-board staff members, who are assumed to be trusted by virtue of the hiring process. It also allows trusted organisations to grant access to volunteers who are well known and trusted by those organisations.
WMF employees may be added to the wmf group in LDAP when they are hired.
Wikimedia Deutschland employees may be added to the wmde group in LDAP when they are hired.
TechCom, or the CTO in consultation with TechCom, may direct a Gerrit administrator to add any person to a Gerrit group.
Revocation
Revocation of Gerrit rights is permitted in the following circumstances:
- In an emergency, such as a compromised account, Gerrit administrators may revoke access immediately, at their discretion. Reversal of emergency revocation may be done at the administrator's discretion if the emergency is judged to have passed. TechCom, or the CTO in consultation with TechCom, may review an emergency revocation and direct its reversal.
- Revocation of privileges of a WMF employee may be directed by that employee's manager, in consultation with WMF Talent and Culture, as discussed in the Staff Handbook.
- Revocation of privileges from any person may be directed by TechCom, or by the CTO in consultation with TechCom.
The reasons for revocation may include:
- Merging bad code
- Merging your own code without review
- Failing to socialize high impact changes within the development community
- Not following the guidelines above
- Inappropriate behaviour, in particular, violating the Code of Conduct
- Termination of employment or contract
It is WMF policy to revoke all privileges when staff members depart, even if those privileges were granted prior to the beginning of employment by virtue of volunteer work. Consistent application of this policy helps to protect the privacy of departing staff members: no fault is implied. If departed staff members wish to continue to contribute in a volunteer capacity, they may reapply for access by the usual process.
Requesting revocation
Emergency revocation should be requested by directly contacting a Gerrit administrator, for example using IRC. Revocation for reasons of competence or behaviour should generally be handled in private, following a defined escalation path. For more details, refer to the following table:
| Scenario | Action |
|---|---|
|
|
|
|
|
|
Amendments to this policy
Amendments to this policy must be approved by the CTO, in consultation with TechCom.
Definitions
- CTO
- The Chief Technology Officer of the Wikimedia Foundation.
- TechCom
- The Wikimedia Technical Committee. For TechCom to decide or direct something means that a meeting of the committee, by remote audio/video conference or in person, with the attendance of a quorum of at least half of TechCom's members, passes a resolution by simple majority or unanimous consent.