Require multiple reviewers for pull requests
blog.github.com
Require multiple reviewers for pull requests
1–10 of 37 posts
Re: Require multiple reviewers for pull requests
#2I think the next step from here is giving the ability to assign maintainers for certain sets of files (in this directory or matching a particular regex) and then when a pull request comes in, GH can looked at the changes, match the maintainers, and require all of them to sign off prior to allowing merging.
Re: Require multiple reviewers for pull requests
#3I think the next step from here is giving the ability to assign maintainers for certain sets of files (in this directory or matching a particular regex) and then when a pull request comes in, GH can looked at the changes, match the maintainers, and require all of them to sign off prior to allowing merging.
There is already a method in place for this with a CODEOWNERS file. It will automatically add reviewers for different paths in the repository.
Re: Require multiple reviewers for pull requests
#4I think the next step from here is giving the ability to assign maintainers for certain sets of files (in this directory or matching a particular regex) and then when a pull request comes in, GH can looked at the changes, match the maintainers, and require all of them to sign off prior to allowing merging.
Have you seen their CODEOWNERS feature? https://help.github.com/articles/about-codeowners/ there is a check box to enforce reviews by owners.
Chrome/Google have something like that but more flexible (e.g. you can have nested OWNERS files) called OWNERS https://chromium.googlesource.com/chromium/src/+/master/docs...
There's a more general/kinda crazy system in Gerrit (by Google) that let's you write custom rules in Prolog (which helps for solving for a minimal set of reviewers that could approve a given PR.) I'm not sure if it gets much use but its a neat thought for sure: https://gerrit-review.googlesource.com/Documentation/prolog-... (which links to this email explaining why: https://groups.google.com/d/msg/repo-discuss/wJxTGhlHZMM/Tal... )
Re: Require multiple reviewers for pull requests
#5TLDR: github has a new feature that allows you to require X number of people to approve a PR before merging to a protected branch.
From the title, I initially thought this would be an article about why you should have multiple people reviewing PRs, which sounded ridiculous (obviously we don't all have the time/resources for that).
Re: Require multiple reviewers for pull requests
#6I think the next step from here is giving the ability to assign maintainers for certain sets of files (in this directory or matching a particular regex) and then when a pull request comes in, GH can looked at the changes, match the maintainers, and require all of them to sign off prior to allowing merging.
Have you seen their CODEOWNERS feature? https://help.github.com/articles/about-codeowners/ there is a check box to enforce reviews by owners. Chrome/Google have something like that but more flexible (e.g. you can have nested OWNERS files) called OWNERS https://chromium.googlesource.com/chromium/src/+/master/docs... There's a more general/kinda crazy system in Gerrit (by Google) that let's you write custom rules in Pr…
CODEOWNERS is a good start, but it only works for the main branch, which means that it doesn't really work well with the Git Flow (https://leanpub.com/git-flow/read). Keeping a different CODEOWNERS file in each branch would be suboptimal, because that means cross-branch merges become a touch nasty. Perhaps if CODEOWNERS was extended to allow matching against rules that also include the branch to be merged into? Alternatively, if that might break existing CODEOWNERS files, doing the same in a MAINTAINERS file might be a viable solution instead.
I think the constraint-solver method in Gerrit is pretty neat, although I could see integrating that into GitHub and devising a non-painful UI for that as a major challenge. However, if they managed to do it, that would be an insanely powerful feature to have, especially for larger or more complex projects.
Re: Require multiple reviewers for pull requests
#7TLDR: github has a new feature that allows you to require X number of people to approve a PR before merging to a protected branch. From the title, I initially thought this would be an article about why you should have multiple people reviewing PRs, which sounded ridiculous (obviously we don't all have the time/resources for that).
Where X is between one and six.
I think perhaps they should have made it infinite, because having a set range causes anchoring. It might seem like 3 is a good choice because 2 is at the low end of things.
Re: Require multiple reviewers for pull requests
#8I think the next step from here is giving the ability to assign maintainers for certain sets of files (in this directory or matching a particular regex) and then when a pull request comes in, GH can looked at the changes, match the maintainers, and require all of them to sign off prior to allowing merging.
FWIW, Reviewable allows you to write a custom review completion condition in JS where you can match paths and participants to your heart's content and determine whether the review is complete or not. This is posted to GitHub as a status check so you can use it to block/allow merging. (Disclaimer: I built Reviewable.)
Re: Require multiple reviewers for pull requests
#9Having multiple reviewers is often bad. A diffusion of responsibility means no responsibility.
If you have three reviewers, no one feels personally responsible for checking it line by line and thinking about the code in depth. Instead a cursory glance seems acceptable, because, after all, other people are looking at it.
Re: Require multiple reviewers for pull requests
#10Blockchain for source control?