| /openbmc/openbmc-tools/tof-voters/libvoters/subcmd/ |
| H A D | analyze-reviews.py | 107 for username, review in comments_per_user.items():
108 if review["comments"] < 3:
110 print(" ", user, review["comments"])
112 user["name"] = review["name"]
113 user["email"] = review["email"]
|
| /openbmc/openbmc-build-scripts/jenkins/ |
| H A D | userid-validation | 27 "${GERRIT_SSH_CMD[@]}" review \
34 "${GERRIT_SSH_CMD[@]}" review \
114 "${GERRIT_SSH_CMD[@]}" review \
120 "${GERRIT_SSH_CMD[@]}" review \
128 "${GERRIT_SSH_CMD[@]}" review \
|
| /openbmc/docs/development/ |
| H A D | gerrit-setup.md | 83 message which Gerrit uses to track the review.
88 changes and push them to Gerrit for code review. Here is what the basic workflow
97 - Push your changes to Gerrit for code review:
100 review, and add reviewers based on `OWNERS` file in the repo.
105 set up Gerrit and know how to submit your code changes for review!
107 Submitting changes for review is just one of many steps in the contributing
|
| /openbmc/linux/Documentation/maintainer/ |
| H A D | feature-and-driver-maintainers.rst | 16 git trees but instead send and review patches on the list of a larger
25 when the work does arrive (in form of patches which need review,
32 The patch review SLA the subsystem had set for itself can sometimes
35 review delay of the subsystem maintainer. The resulting expectations
54 Maintainers must review *all* patches touching exclusively their drivers,
56 multiple drivers - whether to provide a review is left to the maintainer.
59 or ``Reviewed-by`` tag (or review comments) from a single maintainer is
62 If the review process or validation for a particular change will take longer
63 than the expected review timeline for the subsystem, maintainer should
|
| /openbmc/docs/ |
| H A D | community-membership.md | 10 | Designated Reviewer | Review contributions from other members | History of review …
19 helped with review workflow, and directed to relevant documentation and
45 - Contributing to design review, subproject, or community discussions (e.g.
89 - May also review for more holistic issues, but not a requirement
90 - Expected to be responsive to review requests as per [community expectations]
91 - Assigned changes to review related to subproject of expertise
96 Platform maintainers are able to review configuration changes for quality and
129 - Expected to be responsive to review requests as per [community expectations]
130 - Assigned changes to review and test related to the platform
137 Code approvers are able to both review and approve code contributions. While
[all …]
|
| H A D | CONTRIBUTING.md | 67 button. Then select a review. Remember to be positive and add value with every
68 review comment.
160 We use git for almost everything. Most projects in OpenBMC use Gerrit to review
178 - Work at most a few days before seeking review.
179 - Commit and review header files before writing code.
180 - Commit and review each implementation module separately.
184 push commits which are based on your change still in review. However, when
214 whitespace changes - this makes review unnecessarily difficult.
323 [Change-Ids](https://gerrit-review.googlesource.com/Documentation/user-changeid.html)
324 to identify commits that belong to the same review. Configure your git
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | submitting-a-patch.rst | 9 help make our task of contribution review easier and your change is
25 * - Be prepared to respond to review comments
26 - Code that doesn't pass review will not get merged. See :ref:`participating_in_code_review`
103 Make code motion patches easy to review
107 making the refactoring easier to review. Split up the series so that
284 Send patches inline so they are easy to reply to with review comments.
361 When reviewers don't know your goal at the start of their review, they
364 their review. A series where the goal is unclear also risks a higher
365 number of review-fix cycles because the reviewers haven't bought into
382 review on it anyway. Reasons for doing this include:
[all …]
|
| /openbmc/docs/designs/ |
| H A D | design-template.md | 25 may learn of new requirements during the design review process that could
41 ASCII diagrams. Plain text will allow the review to proceed without having to
45 - Once ready for review, submit to gerrit and set the topic of the review to
82 the details you know about the problem space, so they can help review your
113 - Make a list, and add listed repository maintainers to the gerrit review.
|
| /openbmc/linux/Documentation/admin-guide/ |
| H A D | braille-console.rst | 22 mode). To review previous messages, press the Insert key to switch to the VT
23 review mode. In review mode, the arrow keys permit to browse in the VT content,
|
| /openbmc/openbmc/poky/ |
| H A D | MAINTAINERS.md | 11 list review process. Changes therefore undergo peer review through mailing
17 particular areas, during review patches/feedback from these people in these
|
| /openbmc/webui-vue/ |
| H A D | CONTRIBUTING.md | 23 The OpenBMC projects use Gerrit for code review. Use the
30 create a fork from GitHub. Read more about submitting a code review in the
122 When making changes to an existing design, we create a design review issue in
123 GitHub. We then send an email to the community and review the changes in the
152 1. Push your changes to Gerrit for code review:
|
| /openbmc/ibm-dbus-interfaces/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/linux/Documentation/process/ |
| H A D | stable-kernel-rules.rst | 39 Security patches should not be handled (solely) by the -stable review
177 If accepted, the patch will be added to the -stable queue, for review by other
184 - When the -stable maintainers decide for a review cycle, the patches will be
185 sent to the review committee, and the maintainer of the affected area of
188 - The review committee has 48 hours in which to ACK or NAK the patch.
201 - At the end of the review cycle, the new -stable release will be released
204 security kernel team, and not go through the normal review cycle.
|
| /openbmc/openpower-host-ipmi-oem/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/ibm-logging/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/phosphor-webui/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/pyphosphor/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/phosphor-state-manager/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/phosphor-mrw-tools/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/phosphor-watchdog/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/gpioplus/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/slpd-lite/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/sdeventplus/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/phosphor-dbus-monitor/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|
| /openbmc/s2600wf-misc/ |
| H A D | OWNERS | 5 # parts of this repository, including code review and approval. We use the
20 # * reviewers: A list of individuals who have requested review notification
|