Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRFC: Commit access for outside contributors #2958
Comments
This comment has been minimized.
This comment has been minimized.
Hi!
As for me, I used "Automerge" label when I have some small change to commit, but I want PR to pass CI checks. So, I make PR, give it "Automerge" label and bot cares about PR, not me. Next time, if I see what CI has failed, I will resolve that issue, or take no more care if CI succeeds.
At practice, there was cases when PR has approved maintainer review, but was not merged by anybody. Also, this mades impossible to require review from two (or more) maintainers, when one checks code style and other can check implementation details. Should we give it up?
Will this change make it impossible to merge PR by maintainers w/o Code Owner Review? This unclear for me a bit. "Code Owner Review" implementation can make things faster to merge, which is attractive for committers. |
This comment has been minimized.
This comment has been minimized.
Hi Pavel! Thanks for your feedback. To clarify, my goal is to allow contributors to maintain "their" plugin without being blocked by us maintainers. Maybe we can achieve this with Github's owner concept alone, i.e. without involving the bot. For example, consider this config:
We could then add "individual-author" as an outside contributor. This user should then be able to approve (and merge) changes to The other example, |
This comment has been minimized.
This comment has been minimized.
So, if
I just don’t want to catch a situation when maintainer will not be able to merge commit w/o code owner. |
This comment has been minimized.
This comment has been minimized.
The intention is that changes to |
This comment has been minimized.
This comment has been minimized.
Сounterexample: PR 2874. It has two approves from |
This comment has been minimized.
This comment has been minimized.
My expectation would be for Github to block the commit until you are happy and change the status of your review to |
This comment has been minimized.
This comment has been minimized.
... Then team of committers can do /relatively/ fast approve, so I'll be late )) |
This comment has been minimized.
This comment has been minimized.
That's precisely my goal |
This comment has been minimized.
This comment has been minimized.
I am afraid that speed will be at the price of quality. I propose to analyze a couple of examples from the latest merges. |
This comment has been minimized.
This comment has been minimized.
I absolutely understand that concern – I had the same concern every time I gave commit access to someone. My experience has been, though, that if you trust people they will repay you by behaving responsibly. That said, if it doesn't work out and we come to the conclusion that revoking commit access from an outside contributors will reduce work for maintainers, we can (and should) do that. |
octo
changed the title
RFC: Automatic merging
RFC: Commit access for outside contributors
Oct 20, 2018
octo
referenced this issue
Oct 25, 2018
Merged
Tree wide: Move utilities and libraries to src/utils/. #2961
octo
referenced this issue
Jan 31, 2019
Merged
CODEOWNERS: Add code owners as discussed at the meetup. #3053
octo
added
the
core
label
Feb 2, 2019
This comment has been minimized.
This comment has been minimized.
FYI, we're testing this with a couple of people from Intel. If this works well, we'll try to get this established more broadly. |
octo commentedOct 17, 2018
CC: @rubenk, @rpv-tomsk, @tokkee
Hi team,
as you may be aware, the
Automerge
label will cause @collectd-bot to automatically merge pull requests when certain conditions are met (CI succeeds, no pending reviews, …). I'm thinking about changing the behavior a bit and would like your thoughts on this:Automerge
label. I.e. as soon as a maintainer approves a change, it will automatically get merged (assuming CI is successful).src/dpdk{events,stat}.c
, then a (positive) review from one of the Intel folks working on this should be sufficient to trigger the merge. We should encourage contributors to add themselves as owners of new plugins.Caveats:
What do you think?
Best regards,
—octo