letsencrypt
/
boulder
mirror of https://github.com/letsencrypt/boulder.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update review policy in CONTRIBUTING.md. (#4684) 

This is more a change in emphasis than in basic meaning, since
single-review merges are already acceptable.
This commit is contained in:
Jacob Hoffman-Andrews 2020-02-20 16:40:34 -08:00 committed by GitHub
parent 27e785f3f2
commit 9a86abc155
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
CONTRIBUTING.md
View File

@ -6,9 +6,7 @@ Thanks for helping us build Boulder! This page contains requirements and guideli
* We prefer pull requests from external forks be created with the ["Allow edits from maintainers"](https://github.com/blog/2247-improving-collaboration-with-forks) checkbox selected.
# Review Requirements
* All pull requests must receive at least one positive review. Contributors are
strongly encouraged to get two positive reviews before merging whenever
possible.
* All pull requests must receive at least one approval through the GitHub UI.
* We indicate review approval through GitHub's code review facility.
* New commits pushed to a branch invalidate previous reviews. In other words, a reviewer must give positive reviews of a branch after its most recent pushed commit.
* You cannot review your own code.
@ -30,7 +28,7 @@ Thanks for helping us build Boulder! This page contains requirements and guideli
# Squash merging
Once a pull requests has two reviews and the tests are passing, we'll merge it. We always use [squash merges](https://github.com/blog/2141-squash-your-commits) via GitHub's web interface. That means that during the course of your review you should generally not squash or amend commits, or force push. Even if the changes in each commit are small, keeping them separate makes it easier for us to review incremental changes to a pull request. Rest assured that those tiny changes will get squashed into a nice meaningful-size commit when we merge.
Once a pull request is approved and the tests are passing, the author or any other committer can merge it. We always use [squash merges](https://github.com/blog/2141-squash-your-commits) via GitHub's web interface. That means that during the course of your review you should generally not squash or amend commits, or force push. Even if the changes in each commit are small, keeping them separate makes it easier for us to review incremental changes to a pull request. Rest assured that those tiny changes will get squashed into a nice meaningful-size commit when we merge.
If the Travis tests are failing on your branch, you should look at the logs to figure out why. Sometimes (though rarely) they fail spuriously, in which case you can post a comment requesting that a project owner kick the build.