[core-workflow] self-approving pull requests
Donald Stufft
donald at stufft.io
Fri Feb 17 18:24:54 EST 2017
We turned on require code review for the PR, though at the time I *thought* it still allowed you to approve your own PR. Apparently that was wrong. Brett was the one to actually make the decision to do it and turned it on, so I don’t know if he knew that it didn’t allow people to self-approve or not. The impetus to do this was to make sure that all changes went through the PR process and folks didn’t directly push to `master`.
So our choices at this time are:
1) Leave it requiring a review from someone else with write or admin permissions on the repository, which will continue to require a PR.
2) Turn it off, but turn on requiring status checks which will still effectively require a PR (there is one way around this, but it is so convoluted nobody would be able to do it by accident, and things still get tested anyways).
3) Turn them both off, and just tell people not to push to `master` directly and always go through the PR process.
Personally I think that (2) is a good option if our test suite is stable on Travis now. We *want* to make core contributors to generally go through the same process as non-core contributors in order to better expose pain points introduced by our process so we can find them and fix them. Although arguably reviewer bandwidth is a pain point in our process I think that it might be special enough to just switch to the required status check instead.
> On Feb 17, 2017, at 5:39 PM, Barry Warsaw <barry at python.org> wrote:
>
> I submitted PR#138 on bpo-22807. I got a nice review from a community member
> and made a small change. All checks have passed.
>
> But now I'm stuck and I'm impatient. ;)
>
> The change is small enough and I'm happy with it, and I could patiently wait
> for another core dev to approve it, but in the likely case that no one else is
> interested in the bug, I'd like to be able to self-approve and accept it.
> This of course is described as my right in the devguide, along with the
> responsibility to watch the buildbots and revert the change if there are any
> problems with it.
>
> But it seems like I cannot do that through the GH UI. Right now I'm seeing
>
> (X) Review required
> (✓) All checks have passed
> (X) Merge is blocked
>
> There seems to be no way to self-approve the PR. If I go to 'Files changed'
> tab and click on 'Review changes', both Approve and Request changes is
> dimmed. I can only comment on my own PR.
>
> I can understand why we might want to prohibit self-approvals, but that's also
> a regression in the permissions and rights of core developers. I also think
> it's counterproductive since without that I might have to go begging for a
> review approval before the branch can land.
>
> Is this intentional or an oversight?
>
> (As an owner of the project, I took a quick look at the project settings and
> couldn't find a control for this, but I know other GH projects I contribute to
> support self-approval.)
>
> Cheers,
> -Barry
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
—
Donald Stufft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170217/fa047f44/attachment.html>
More information about the core-workflow
mailing list