RFC: Commit access for outside contributors

[octo]

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:

1. Require one "approved" review from one of the maintainers instead of the Automerge label. I.e. as soon as a maintainer approves a change, it will automatically get merged (assuming CI is successful).
2. As a second step, I'd like to integrate with Github's code ownership concept. When, for example, a pull request only touches 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:

• You can now "resolve" code review comments in the UI, but as far as I see it's not possible to distinguish "resolved" from "unresolved" comments in the API. That means you'd have to ensure all comments are fixed before approving.
• It's unclear how much of the code ownership we have to implement ourselves. I'm hoping that with the "Require review from Code Owner" option enabled a PR is simply marked as "not mergable" unless the condition is met. But the API docs are extremely vague with details like this.

What do you think?

Best regards,
—octo

[rpv-tomsk]

Hi!

Require one "approved" review from one of the maintainers instead of the Automerge label. I.e. as soon as a maintainer approves a change, it will automatically get merged (assuming CI is successful).

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.
(Ok, I also check, if CI of master has not failed after merge of succeeded PR check, that can happen, unfortunately.)

Require one "approved" review from one of the maintainers instead of the Automerge label. I.e. as soon as a maintainer approves a change, it will automatically get merged (assuming CI is successful).

At practice, there was cases when PR has approved maintainer review, but was not merged by anybody.
Proposed change will cover such cases, but most of the time, I think, when maintainer reviews PR, it already has CI checks completed, so he can just do merge directly. If maintainer doesn't want to take responsibility of merge, then he will not approve PR at all after such change.

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?

---

I'm hoping that with the "Require review from Code Owner" option enabled a PR is simply marked as "not mergable" unless the condition is met.

With protected branches enabled, a code owner for each owned file has to leave a review before anyone can merge a pull request to that branch.

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.
But we also need to have more transparent release cycle and list of supported versions.

[octo]

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:

# These owners will be the default owners for everything in the repo.
*       @collectd/maintainers

# Docs
/README @collectd/everybody
*.pod   @collectd/everybody

/src/example.c  @individual-author
/src/dpdkstat.c @contributor1 @contributor2

We could then add "individual-author" as an outside contributor. This user should then be able to approve (and merge) changes to src/example.c. Changes by "individual-author" themselves should still require a review by one of the maintainers though.

The other example, src/dpdkstat.c, would allow "contributor1" and "contributor2" to work together to maintain that code – without any involvement of the core maintainers.

[rpv-tomsk]

So, if example.c has two Code Owners, then one can put PR and only second owner can approve it? Sounds good.

With protected branches enabled, a code owner for each owned file has to leave a review before anyone can merge a pull request to that branch.

I just don’t want to catch a situation when maintainer will not be able to merge commit w/o code owner.

[octo]

The intention is that changes to example.c require approval from the plugin owner(s) or a "core maintainer" (the GitHub docs call these "global owners").

[rpv-tomsk]

Сounterexample: PR #2874. It has two approves from code owners and change request from me.

[octo]

My expectation would be for Github to block the commit until you are happy and change the status of your review to APPROVED. In other words, for 2874 your review should not be required, but if you chose to do a review merging should be blocked until you too approve the changes.

[rpv-tomsk]

... Then team of committers can do /relatively/ fast approve, so I'll be late ))
Maybe there is 'grace period' exits ? )

[octo]

team of committers can do /relatively/ fast approve

That's precisely my goal 😁 I'd like the "core maintainers to be less of a bottle neck and allow outside contributors to move fast, without giving away the keys to the castle, so to speak.

[rpv-tomsk]

I am afraid that speed will be at the price of quality.

I propose to analyze a couple of examples from the latest merges.

[octo]

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]

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.