Review-then-merge

From PRPL
Jump to: navigation, search

In the review-then-merge system for code modifications, changes to the code base happen after a review and vote of the project community. The intent of the review-then-merge system is to create and maintain a stable branch of code.

Review-then-merge process[edit]

Contributor makes a pull request[edit]

The contributor who has made a change (the requester) makes a pull request on the project repository. The pull requester is expected to email the mailing list of project to notify them of a pull request.

Does pull request comply with the IP policy?[edit]

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 AND the committer announces on the pull request that they will use lazy consensus[edit]

Committers may use lazy consensus to simplify the process of handling pull requests. If they announce on the pull request that they'd like to use lazy consensus, the following process is used.

Community members comment and discuss the pull request[edit]

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[edit]

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:

  • 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[edit]

The pull request is merged by a committer.

Requester is NOT committer OR a committer but doesn't ask for lazy consensus[edit]

Community members comment and discuss the pull request[edit]

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[edit]

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[edit]

The pull request is merged by a committer.

Diagram[edit]

A diagram of the process is below:

Review then merge.png