In the merge-then-review system for code modifications, committers can commit code to a branch without prior review. Any community member may request a review of code that once it has been merged and, if they see fit, they may veto the code change and have the change removed. The intent of this system to allow rapid development and prototyping while still allowing any member of the community veto authority as in the Review-then-merge system. prpl uses merge-then-review for feature branches.
- 1 Merge-then-review process
- 1.1 Contributor makes a pull request
- 1.2 Does pull request comply with the IP policy?
- 1.3 Requester is a committer
- 1.4 Requester is NOT a committer
- 2 Diagram
Contributor makes a pull request
The contributor who has made a change (the requester) makes a pull request on the project repository.
Does pull request comply with the IP policy?
A committer verifies that the pull request compiles with the IP Policy. If it does not, the request is put on hold until the requester fixes their commits to comply with the IP policy
Requester is a committer
Committer may merge the pull request
The committer may merge the pull request immediately.
While the merge is immediate, this pull request can be reverted later by in the review process.
The review process of the merge-then-review system exists to prevent a committer from abusing their authority. Without it, a committer could merge pull requests that are not in the best interest of the community and veto any reversion of that change.
The process begins when a community members wants to discuss the contents of a merged pull request, either through the mailing list or the now-closed pull request. The community discusses the pull request and, if after a reasonable period of discussion, a community member may veto the original pull request. A committer will then revert the pull request from the branch.
Requester is NOT a committer
This process is very similar to how pull requests are reviewed in the review-then-merge system.
Community members comment and discuss the pull request
The pull request is reviewed by the community. Interested community members comment on the pull request and discuss its pros and cons. These comments should occur on the Github page for the pull request.
Community members vote on the the pull request
On the pull request page, community members vote on whether the pull request should be merged. The members can vote in the pull request comments at any point.
After 72 hours have passed since the pull request was made or the last change was made to the pull request (whichever was later), the pull request can be merged if the following conditions are true:
- At least three votes are made in support (+1 votes)
- No vetos are made (-1 votes)
Community members can change their vote at any point in the pull request. Vetos can be rescinded and positives votes can be changed to vetos. The conditions should be evaluated based on the last vote for each of the individuals voting.
If the merge vote doesn't succeed, the pull request can stay open or be removed at the discretion of the requester. If the merge vote succeeds, we go to the next step.
Committer merges the pull request
The pull request is merged by a committer.
The diagram below summarizes the merge-then-review system: