4 ms·

I 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 the

I 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.

cakeface 9y ago
There is already a method in place for this with a CODEOWNERS file. It will automatically add reviewers for different paths in the repository.
jacobparker 9y ago
Have you seen their CODEOWNERS feature? https://help.github.com/articles/about-codeowners/ 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/code_reviews.md#owners-files 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-cookbook.html https://gerrit-review.googlesource.com/Documentation/prolog-... (which links to this email explaining why: https://groups.google.com/d/msg/repo-discuss/wJxTGhlHZMM/TalGqOeo0GYJ https://groups.google.com/d/msg/repo-discuss/wJxTGhlHZMM/Tal... )
- haneefmubarak 9y ago
  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 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.
piotrkaminski 9y ago
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.)
OnlyRepliesToBS 9y ago
Never work at places that do this shit. The bureaucracy is growing for its own sake. It should be about product, not fucking policy.

cakeface 9y ago

There is already a method in place for this with a CODEOWNERS file. It will automatically add reviewers for different paths in the repository.

jacobparker 9y ago

Have you seen their CODEOWNERS feature? https://help.github.com/articles/about-codeowners/ 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/code_reviews.md#owners-files 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-cookbook.html https://gerrit-review.googlesource.com/Documentation/prolog-... (which links to this email explaining why: https://groups.google.com/d/msg/repo-discuss/wJxTGhlHZMM/TalGqOeo0GYJ https://groups.google.com/d/msg/repo-discuss/wJxTGhlHZMM/Tal... )

haneefmubarak 9y ago
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 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.

piotrkaminski 9y ago

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.)

OnlyRepliesToBS 9y ago

Never work at places that do this shit. The bureaucracy is growing for its own sake. It should be about product, not fucking policy.