/openbmc/openbmc-tools/tof-voters/libvoters/subcmd/ |
H A D | analyze-reviews.py | 74 reviewer = comment["reviewer"]["username"] 76 if reviewer == author: 81 user = comments_per_user[reviewer]
|
/openbmc/openbmc-build-scripts/tools/ |
H A D | owners | 152 def review_js(reviewer: str, state: str) -> str: 155 "reviewer": reviewer, 158 "notify_details": {"TO": {"accounts": [reviewer]}},
|
/openbmc/openbmc-build-scripts/jenkins/ |
H A D | userid-validation | 41 while read -r reviewer ; 47 -d "$reviewer" || true
|
/openbmc/phosphor-pcie-presence/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/openpower-sbe-interface/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/phosphor-mboxd/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/pyphosphor/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/inarp/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/openpower-inventory-upload/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/openpower-logging/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/phosphor-event/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/boost-dbus/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/google-ipmi-sys/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/libbej/ |
H A D | MAINTAINERS | 30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; 40 approval; thus, a MAINTAINER should always be listed as a reviewer.
|
/openbmc/docs/ |
H A D | community-membership.md | 10 … | [OWNERS] file reviewer entry … 68 reviewer in an [OWNERS] file. 71 - Primary reviewer for at least 5 changes to the codebase 81 The following apply to the part of codebase for which one would be a reviewer in 84 - Code reviewer status may be a precondition to accepting large code 109 - Primary reviewer for at least 5 reviews to the codebase 120 The following apply to the part of codebase for which one would be a reviewer in 153 - Primary reviewer for at least 10 substantial changes to the codebase
|
H A D | meta-layer-guidelines.md | 22 maintainer is not a reviewer, thereby defeating most of the purpose of the role
|
/openbmc/webui-vue/.github/ISSUE_TEMPLATE/ |
H A D | design-review.md | 15 The Invision prototypes have hot spots allowing the reviewer to step through the
|
/openbmc/qemu/docs/devel/ |
H A D | maintainers.rst | 59 Becoming a reviewer 68 marks you as a 'designated reviewer' - expected to provide regular
|
H A D | submitting-a-patch.rst | 362 reviewer, the process will be smoother patches will get merged faster. 462 doing everything the reviewer asked. On the other hand, if someone 526 When reviewing a large series, a reviewer can reply to some of the 535 version, to make it easier to focus a reviewer's attention to your
|
/openbmc/linux/Documentation/process/ |
H A D | 6.Followthrough.rst | 65 understand what the reviewer is trying to say. If possible, fix the things 66 that the reviewer is asking you to fix. And respond back to the reviewer: 70 reviewers. If you believe that the reviewer has misunderstood your code, 73 your explanations make sense, the reviewer will accept them. Should your 75 agree with the reviewer, take some time to think things over again. It can
|
H A D | submitting-patches.rst | 50 motivated you to do this work. Convince the reviewer that there is a 70 optimization so that the reviewer can weigh costs against benefits. 74 in plain English for the reviewer to verify that the code is behaving 320 bring about a comment or changelog entry so that the next reviewer better 570 technical issues. Any interested reviewer (who has done the work) can 578 or reviewer, should be added by author to the applicable patches when sending 814 bottom, which provides the reviewer and the CI tools enough information
|
H A D | maintainer-netdev.rst | 305 reviewer. You can start with using ``checkpatch.pl``, perhaps even with 334 Put yourself in the shoes of the reviewer. Each patch is read separately 392 ongoing, unless directly instructed by a reviewer.
|
H A D | researcher-guidelines.rst | 154 Reviewed-by: Reviewer <reviewer@email>
|
/openbmc/openbmc/ |
H A D | README.md | 94 performed by the reviewer.
|
/openbmc/linux/Documentation/translations/sp_SP/process/ |
H A D | researcher-guidelines.rst | 134 Reviewed-by: Reviewer <reviewer@email>
|