| /openbmc/docs/ |
| H A D | community-membership.md | 10 | Designated Reviewer | Review contributions from other members | History of review …
11 | Platform Maintainer | Review and maintain contributions to a single platform | History of testing…
12 | Approver | Review and maintain contributions to a portion of code | Demonstrated respo…
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]
[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 …]
|
| H A D | meta-layer-guidelines.md | 21 in code review. If patches are checked into meta layers, generally the
30 through a gerrit review, and follow the processes outlined for the repository.
49 cherry-pick the commit into the OpenBMC tree, with a pointer to the review in
92 bypass code review by pointing the upstream recipe to a public repository that
|
| /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/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/openbmc/poky/meta/lib/oeqa/manual/ |
| H A D | kernel-dev.json | 18 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
40 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
62 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
84 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
106 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
128 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
150 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
172 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
194 …"expected_results": "Review expected results on thethe \"Kernel Development Test Cases\"wiki. http…
|
| /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/docs/development/ |
| H A D | gerrit-setup.md | 92 message which Gerrit uses to track the review.
97 changes and push them to Gerrit for code review. Here is what the basic workflow
106 - Push your changes to Gerrit for code review:
109 review, and add reviewers based on `OWNERS` file in the repo.
114 set up Gerrit and know how to submit your code changes for review!
116 Submitting changes for review is just one of many steps in the contributing
|
| /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
181 Review cycle
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.
231 Review committee
|
| H A D | 6.Followthrough.rst | 26 developers as they review the code. Working with reviewers can be, for
39 - Code review is hard work, and it is a relatively thankless occupation;
43 review which seems angry, insulting, or outright offensive, resist the
44 impulse to respond in kind. Code review is about the code, not about
64 from happening. When you get review comments on a patch, take the time to
80 Andrew Morton has suggested that every review comment which does not result
85 One fatal mistake is to ignore review comments in the hope that they will
115 most of the review issues have been resolved, the next step is usually
|
| H A D | maintainer-netdev.rst | 33 Linux development (i.e. RFC, review, comments, etc.) takes place on
89 RFC patches sent for review only are obviously welcome at any time
109 netdev patch review
128 New, Under review pending review, patch is in the maintainer’s queue for
129 review; the two states are used interchangeably (depending on
134 Changes requested patch has not passed the review, new revision is expected
148 RFC not to be applied, usually not in maintainer’s review queue,
190 Review timelines
339 to review as reviewers will defer looking at it until they find a large
342 with better review coverage. Re-posting large series also increases the mailing
[all …]
|
| H A D | 1.Intro.rst | 19 the patch development, review, and merging cycle are covered. There is some
33 review. To be taken seriously by the development community, patches must be
158 - Kernel code is subjected to review, both before and after merging into
160 this review process invariably finds ways in which the code can be
161 improved. Often review finds severe bugs and security problems. This is
163 environment; such code benefits strongly from review by outside
215 - Everything that was said above about code review applies doubly to
224 widespread code review and the value of allowing your users to add
|
| H A D | 7.AdvancedTopics.rst | 116 slip in ill-advised changes which go into the mainline below the review
133 importantly, do not use a git tree to bypass the review process. Post an
138 don't forget to review them. Also ensure that you maintain the correct
165 piece of advice for reviewers (all reviewers) is this: phrase review
170 Different developers will review code from different points of view. Some
177 All types of review, if they lead to better code going into the kernel, are
|
| H A D | clang-format.rst | 16 you maintain, patches you review, diffs, etc. See clangformatreview_.
46 Review files and patches for coding style
49 By running the tool in its inline mode, you can review full subsystems,
63 ``clang-format`` also supports reading unified diffs, so you can review
|
| /openbmc/openbmc-tools/tof-voters/libvoters/subcmd/ |
| H A D | analyze-reviews.py | 112 for username, review in comments_per_user.items():
113 if review["comments"] < 3:
115 print(" ", user, review["comments"])
117 user["name"] = review["name"]
118 user["email"] = review["email"]
|
| /openbmc/openbmc-build-scripts/jenkins/ |
| H A D | userid-validation | 27 "${GERRIT_SSH_CMD[@]}" review \
34 "${GERRIT_SSH_CMD[@]}" review \
117 "${GERRIT_SSH_CMD[@]}" review \
123 "${GERRIT_SSH_CMD[@]}" review \
131 "${GERRIT_SSH_CMD[@]}" review \
|
| /openbmc/phosphor-host-ipmid/docs/ |
| H A D | contributing.md | 20 push commits which are based on your change still in review. However, when
84 Like most projects in OpenBMC, we use Gerrit to review patches. Please check the
85 MAINTAINERS file to determine who needs to approve your review in order for your
88 the commit if they have not been added to the review!
90 ## Pace of Review
97 have very deep review queues already of patches which have been waiting longer
|
| /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/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/docs/security/ |
| H A D | obmc-security-response-team-guidelines.md | 66 3. Negotiate how the code review will proceed.
73 - Make the Gerrit review publicly viewable.
77 Repository maintainer process steps: 1. Create a private gerrit code review and
81 and other stakeholders to the advisory. 3. Review the security bulletin with
92 coordinated disclosure), please merge the fixes (and make any private review be
105 https://gerrit-review.googlesource.com/Documentation/intro-user.html#private-changes
|
| /openbmc/linux/Documentation/nvdimm/ |
| H A D | maintainer-entry-profile.rst | 51 patch set requires more than 2 weeks of review, -rc4 is already too late
52 and some patches may require multiple development cycles to review.
55 Review Cadence
|
| /openbmc/openbmc/poky/documentation/contributor-guide/ |
| H A D | submit-changes.rst | 23 One significant factor is that we value peer review. When a change is proposed
24 to many of the core pieces of the project, it helps to have many eyes of review
26 final call on accepting or rejecting a patch, the review is made by many eyes
31 maintainer makes that review, or review is specifically requested from
33 by this peer review and that moving away from mailing lists would be to the
102 isolated ones. Keeping changes small and isolated aids review, makes
312 #. *Review each of the Patch Files:* This final review of the patches
315 or even files that you didn't intend to modify. This review should
319 ":ref:`contributor-guide/submit-changes:taking patch review into account`".
359 quality of your changes before they are submitted for review by the
[all …]
|
| /openbmc/webui-vue/.github/ISSUE_TEMPLATE/ |
| H A D | design-review.md | 2 name: Design review
21 ## Design Review Workflow
|
| /openbmc/linux/Documentation/hwmon/ |
| H A D | submitting-patches.rst | 30 and review the code.
52 to review your changes, and to bisect any resulting problems.
80 checkpatch, but also makes it more difficult to review the code.
84 review more difficult. It may also result in code which is more complicated
|