Lines Matching +full:merge +full:- +full:pr
1 .. _contributor-expectations:
10 - Reviewed more quickly and reviewed more thoroughly. It's easier for reviewers
12 to allocate large blocks of time to review a large PR.
14 - Less wasted work if reviewers or maintainers reject the direction of the
17 - Easier to rebase and merge. Smaller PRs are less likely to conflict with other
20 - Easier to revert if the PR breaks functionality.
32 - Smaller PRs should encompass one self-contained logical change.
34 - When adding a new large feature or API, the PR should address only one part of
38 - PRs should include tests or samples under the following conditions:
40 - Adding new features or functionality.
42 - Modifying a feature, especially for API behavior contract changes.
44 - Fixing a hardware agnostic bug. The test should fail without the bug fixed
47 - PRs must update any documentation affected by a functional code change.
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:
82 - Submitting a new feature.
83 - Submitting a new API.
84 - :ref:`treewide-changes`.
85 - Other large changes that can benefit from the RFC proposal process.
90 PR Requirements
93 - Each commit in the PR must provide a commit message following the
94 :ref:`commit-guidelines`.
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
101 - Follow the Zephyr :ref:`coding_style` and :ref:`coding_guidelines`.
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
111 - When major new functionality is added, tests for the new functionality shall
118 - :zephyr_file:`Kernel timer tests <tests/kernel/timer/timer_behavior>`
121 - Emulators for off-chip peripherals are an effective way to test driver
127 - Code coverage reports for the Zephyr project are available on `Codecov`_.
129 - Incompatible changes to APIs must also update the release notes for the
133 - Changes to APIs must increment the API version number according to the API
136 - PRs must also satisfy all :ref:`merge_criteria` before a member of the release
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
142 .. _`Codecov`: https://app.codecov.io/gh/zephyrproject-rtos/zephyr
147 - Unless they applied the reviewer's recommendation exactly, authors must not
149 Zephyr project does not require all comments to be resolved before merge.
153 - Respond to comments using the "Start Review" and "Add Review" green buttons in
158 - As GitHub does not implement |git range-diff|_, try to minimize rebases in the
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.
163 .. |git range-diff| replace:: ``git range-diff``
164 .. _`git range-diff`: https://git-scm.com/docs/git-range-diff
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.
215 - Assignee to act as moderator if applicable.
217 - Optionally resolve in the next `Zephyr Dev Meeting`_ meeting with more
220 - The involved parties and the Assignee to be present when the issue is
223 - If no progress is made, the assignee (maintainer) has the right to dismiss
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.
240 - Escalate to the `Architecture Working Group`_ by adding the `Architecture
241 Review` label on the PR. Beside the weekly meeting where such escalations are
246 - If all avenues of resolution and escalation have failed, assignees can escalate
248 on the PR.
250 - The Assignee is expected to ensure the resolution of the escalation and the
253 .. _#pr-help: https://discord.com/channels/720317445772017664/997527108844798012
255 .. _dev-review: https://github.com/zephyrproject-rtos/zephyr/labels/dev-review
257 …ev Meeting: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups#…
259 .. _Architecture Project: https://github.com/zephyrproject-rtos/zephyr/projects/18
261 …hitecture Working Group: https://github.com/zephyrproject-rtos/zephyr/wiki/Architecture-Working-Gr…
264 .. _reviewer-expectations:
269 - Be respectful when commenting on PRs. Refer to the Zephyr `Code of Conduct`_
272 - The Zephyr Project recognizes that reviewers and maintainers have limited
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.
287 - Partial reviews are permitted, but the reviewer must add a comment indicating
288 what portion of the PR they reviewed. Examples of useful partial reviews
291 - Domain specific reviews (e.g. Devicetree).
292 - Code style changes that impact the readability of the PR.
293 - Reviewing commits separately when the requested changes cascade into the
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,
302 - When using the "Request Changes" option, mark trivial, non-functional,
303 requests as "Non-blocking" in the comment. Reviewers should approve PRs once
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
308 - Reviewers shall be *clear* and *concise* what changes they are requesting when the
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.
318 .. _Code of Conduct: https://github.com/zephyrproject-rtos/zephyr/blob/main/CODE_OF_CONDUCT.md
320 .. _Zephyr Release Plan: https://github.com/orgs/zephyrproject-rtos/projects/13