Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Propose change to PR merging policy. #14867

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 19, 2019
Merged

Propose change to PR merging policy. #14867

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 17 additions & 7 deletions doc/devel/coding_guide.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,9 +51,9 @@ PR Review guidelines
the threshold "is this better than it was?" as the review criteria.

* For code changes (anything in ``src`` or ``lib``) at least two
developers (those with commit rights) should review all pull
core developers (those with commit rights) should review all pull
requests. If you are the first to review a PR and approve of the
changes use the github `'approve review'
changes use the GitHub `'approve review'
<https://help.github.com/articles/reviewing-changes-in-pull-requests/>`__
tool to mark it as such. If you are a subsequent reviewer please
approve the review and if you think no more review is needed, merge
Expand All @@ -63,7 +63,19 @@ PR Review guidelines
:file:`doc/api/api_changes` and significant new features have and
entry in :file:`doc/user/whats_new`.

* Make sure the Travis, Appvyor, circle, and codecov tests are passing
- If a PR already has a positive review, a core developer (e.g. the first
reviewer, but not necessarily) may champion that PR for merging. In order
to do so, they should ping all core devs both on GitHub and on the dev
mailing list, and label the PR with the "Merge with single review?" label.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about "and on the dev mailing list"; I rarely see day-to-day pings (as opposed to long-term, more architectural things) happen there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it doesn't cost much to send an email.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean that I don't see it happening regularly...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine either way, but let's see what @tacaswell thinks?

Other core devs can then either review the PR and merge or reject it, or
simply request that it gets a second review before being merged. If no one
asks for such a second review within a week, the PR can then be merged on
the basis of that single review.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, if I am reading this correctly, does this mean that a core dev can effectively put a "hold" on merging a PR? If so, I think that should be made explicit. Will there be a label for that, or does one just need to leave a comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, you can always reject a PR. Or you can just say, "I don't want to reject this PR myself, but I think it is complex enough that I ask for a second positive review before it gets merged." (the "or simply request etc.").
You can probably just remove the "merge-with-single-review" label to signal that.


A core dev should only champion one PR at a time and we should try to keep
the flow of championed PRs reasonable.

* Make sure the Travis, Appveyor, CircleCI, and codecov tests are passing
before merging.

- Whenever a pull request is created or updated, Travis and Appveyor
Expand All @@ -73,7 +85,7 @@ PR Review guidelines

* Do not self merge, except for 'small' patches to un-break the CI or
when another reviewer explicitly allows it (ex, "Approve modulo CI
passing, may self merge when green")
passing, may self merge when green").

* Squashing is case-by-case. The balance is between burden on the
contributor, keeping a relatively clean history, and keeping a
Expand All @@ -94,8 +106,6 @@ PR Review guidelines
with the contributor first.




Branches and Backports
======================

Expand Down Expand Up @@ -159,7 +169,7 @@ We do a backport from master to v2.2.x assuming:
* ``matplotlib`` is a read-only remote branch of the matplotlib/matplotlib repo

The ``TARGET_SHA`` is the hash of the merge commit you would like to
backport. This can be read off of the github PR page (in the UI with
backport. This can be read off of the GitHub PR page (in the UI with
the merge notification) or through the git CLI tools.

Assuming that you already have a local branch ``v2.2.x`` (if not, then
Expand Down