From 6c2e73b5edc1b35c8682ca98c5f56eaef19f74b1 Mon Sep 17 00:00:00 2001 From: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com> Date: Mon, 8 Apr 2024 14:04:47 +0200 Subject: [PATCH 1/2] DOC: Clarify merge policy --- doc/devel/pr_guide.rst | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/doc/devel/pr_guide.rst b/doc/devel/pr_guide.rst index 055998549e78..3529fc8e8723 100644 --- a/doc/devel/pr_guide.rst +++ b/doc/devel/pr_guide.rst @@ -176,18 +176,24 @@ a corresponding branch. Merging ------- +As a guiding principle, we require two `approvals`_ from core developers (those +with commit rights) before merging a pull request. This two-pairs-of-eyes +strategy shall ensure a consistent project direction and prevent accidental +mistakes. It is permissible to merge with one approval if the change is not +fundamental and can easily be reverted at any time in the future. -* Documentation and examples may be merged by the first reviewer. Use +.. _approvals: https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests + +Some explicit rules following from this: + +* *Documentation and examples* may be merged with a single approval. Use the threshold "is this better than it was?" as the review criteria. -* For code changes (anything in ``src`` or ``lib``) at least two - 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' - `__ - 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 - the PR. +* Minor *infrastructure updates*, e.g. temporary pinning of broken dependencies + or small changes to the CI configuration, may be merged with a single + approval. + +* *Code changes* (anything in ``src`` or ``lib``) must have two approvals. Ensure that all API changes are documented in a file in one of the subdirectories of :file:`doc/api/next_api_changes`, and significant new @@ -205,9 +211,11 @@ Merging A core dev should only champion one PR at a time and we should try to keep the flow of championed PRs reasonable. -* 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"). +After giving the last required approval, the author of the approval should +merge the PR. PR authors must not self-merge, except for when another reviewer +explicitly allows it (e.g., "Approve modulo CI passing, may self merge when +green", or "Take or leave the comments. You may self merge".). +Core developers may also self-merge in exceptional emergency situations. .. _pr-automated-tests: From 11de885ed09add6ac18d91877647d713e94cc747 Mon Sep 17 00:00:00 2001 From: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com> Date: Fri, 12 Apr 2024 09:46:43 +0200 Subject: [PATCH 2/2] Update doc/devel/pr_guide.rst Co-authored-by: Thomas A Caswell --- doc/devel/pr_guide.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/devel/pr_guide.rst b/doc/devel/pr_guide.rst index 3529fc8e8723..778d7b3c57bd 100644 --- a/doc/devel/pr_guide.rst +++ b/doc/devel/pr_guide.rst @@ -212,10 +212,9 @@ Some explicit rules following from this: the flow of championed PRs reasonable. After giving the last required approval, the author of the approval should -merge the PR. PR authors must not self-merge, except for when another reviewer +merge the PR. PR authors should not self-merge except for when another reviewer explicitly allows it (e.g., "Approve modulo CI passing, may self merge when green", or "Take or leave the comments. You may self merge".). -Core developers may also self-merge in exceptional emergency situations. .. _pr-automated-tests: pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy