Lines Matching +full:do +full:- +full:not +full:- +full:merge
1 .. _contributor-expectations:
10 - Reviewed more quickly and reviewed more thoroughly. It's easier for reviewers
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.
23 This page does not apply to draft PRs which can have any size, any number of
26 do not notify anyone by default.
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.
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.
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.
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
142 .. _`Codecov`: https://app.codecov.io/gh/zephyrproject-rtos/zephyr
147 - Unless they applied the reviewer's recommendation exactly, authors must not
148 resolve and hide comments, they must let the initial reviewer do it. The
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
163 .. |git range-diff| replace:: ``git range-diff``
164 .. _`git range-diff`: https://git-scm.com/docs/git-range-diff
170 commitment and priorities. As such, reviewers and maintainers may not get to a
185 - After 1 week of inactivity, ping the Assignee or reviewers on the PR by adding
188 - After 2 weeks of inactivity, post a message on the `#pr-help`_ channel on
191 - After 2 weeks of inactivity, add the `dev-review`_ label to the PR. This
193 independent of the triage process. Not all contributors have the required
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
233 expected to block the PR from being merged either by not
240 - Escalate to the `Architecture Working Group`_ by adding the `Architecture
246 - If all avenues of resolution and escalation have failed, assignees can escalate
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
284 - Try to provide feedback on the entire PR in one shot. This provides the
287 - Partial reviews are permitted, but the reviewer must add a comment indicating
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
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
313 - Reviewers shall not close a PR due to technical or structural disagreement.
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