Document the policy of reviews and submittion
We need to document the policy of "Submit" to v4 Core. My suggestion:
Gerrit allows reviewing of patches through a Web UI (http://review.typo3.org). A patch can get:
- +1: Code works by testing
- 0: Have not tested
- -1: Fails
- Code Review:
- +2: Approved
- +1: Could commit, needs more approval
- 0: No opinion, just adding some comment
- -1: Please do not commit
- -2: Veto
Note that "+1" + "+1" is not equals "+2". The +1 is only kind of a "Like it" button, which multiple people can hit (even anonymous reviewers). Only a core developer can ultimately give a +2, approving a change and unlocking the "Submit" button.
We will use the same policy that we used in the core mailing lists, which is:
A patch needs:
- 2 reviews by reading, one of them being a core developer
- 2 reviews by testing, one of them being a core developer
Translating this to Gerrit, this means:
- Needs two +1, one of them being a core developer
- Code Review:
- First one reviewing and liking it, gives a "+1" (regardless if it is a core developer)
- Next reviewer gives "+1" if she is a regular reviewer. If its a core developer, he can give a "+2" right away.
As soon as the patch has reached the approved status, one core developer can decide to push the "Submit" button, finally pushing it to the repository.
#2 Updated by Ernesto Baschny over 8 years ago
Xavier, I would say the same rules apply for patches by core team members (two further reviews by testing and two by reading, one of them each by a core developer).
Since the author of a patch (the one that originally pulled the change to Gerrit) is recorded anyway when the patch is finally committed to core, it doesn't matter who exactly pushes the "Submit" button. The second core developer, if the patch has enough reviews already, could do it.
The one that hits the "Submit" only has the job / responsibility to make sure that the change passed the approval by the defined rules.