Lines Matching full:pr
12 to allocate large blocks of time to review a large PR.
20 - Easier to revert if the PR breaks functionality.
34 - When adding a new large feature or API, the PR should address only one part of
49 - If introducing a new API, the PR must include an example usage of the API.
54 Multiple Commits on a Single PR
58 in mind each commit in the PR must still build cleanly and pass all the CI
62 the PR into multiple commits targeting these specific changes:
90 PR Requirements
93 - Each commit in the PR must provide a commit message following the
96 - The PR description must include a summary of the changes and their rationales.
98 - All files in the PR must comply with :ref:`Licensing
103 - PRs must pass all CI checks. This is a requirement to merge the PR.
104 Contributors may mark a PR as draft and explicitly request reviewers to
107 - When breaking a PR into multiple commits, each commit must build cleanly. The
108 CI system does not enforce this policy, so it is the PR author's
137 engineering team merges the PR into the zephyr tree.
139 Maintainers may request that contributors break up a PR into smaller PRs and may
160 with no other changes since the last push of the PR. When pushing a rebase
161 only, add a comment to the PR indicating which commit is the rebase.
171 PR right away.
177 #. Identify PRs without any comments or reviews, ping the PR Assignee to start a
180 Assignee and any reviewers that have left comments on the PR.
185 - After 1 week of inactivity, ping the Assignee or reviewers on the PR by adding
186 a comment to the PR.
188 - After 2 weeks of inactivity, post a message on the `#pr-help`_ channel on
189 Discord linking to the PR.
191 - After 2 weeks of inactivity, add the `dev-review`_ label to the PR. This
192 explicitly adds the PR to the agenda for the next `Zephyr Dev Meeting`_
205 PR Technical Escalation
213 - Resolve in the PR among assignee, maintainers and reviewer.
229 any reviews in the PR and should notify the reviewer about their review being
233 expected to block the PR from being merged either by not
234 approving the PR or by setting the *DNM* label.
241 Review` label on the PR. Beside the weekly meeting where such escalations are
248 on the PR.
253 .. _#pr-help: https://discord.com/channels/720317445772017664/997527108844798012
281 - Reviewers shall strive to advance the PR to a mergeable state with their
282 feedback and engagement with the PR author.
284 - Try to provide feedback on the entire PR in one shot. This provides the
285 contributor an opportunity to address all comments in the next PR update.
288 what portion of the PR they reviewed. Examples of useful partial reviews
292 - Code style changes that impact the readability of the PR.
296 - Avoid increasing scope of the PR by requesting new features, especially when
297 there is a corresponding :ref:`RFC <rfcs>` associated with the PR. Instead,
304 only non-blocking changes remain. The PR author has discretion as to whether
305 they address all non-blocking comments. PR authors should acknowledge every
310 the PR in question and following the contribution and style guidelines of the
313 - Reviewers shall not close a PR due to technical or structural disagreement.
316 path, which may include closing the PR.