Lines Matching full:the
6 The Zephyr project encourages :ref:`contributors <contributor>` to submit
7 changes as smaller pull requests. Smaller pull requests (PRs) have the following
14 - Less wasted work if reviewers or maintainers reject the direction of the
18 changes in the tree.
20 - Easier to revert if the PR breaks functionality.
25 Draft PRs have no review expectation and PRs created as drafts from the start
34 - When adding a new large feature or API, the PR should address only one part of
35 the feature. In this case create an :ref:`RFC proposal <rfcs>` to describe the
36 additional parts of the feature for reviewers.
38 - PRs should include tests or samples under the following conditions:
44 - Fixing a hardware agnostic bug. The test should fail without the bug fixed
45 and pass with the fix applied.
49 - If introducing a new API, the PR must include an example usage of the API.
50 This provides context to the reviewer and prevents submitting PRs with unused
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:
64 #. Introduce the new APIs, including shared devicetree bindings
67 #. Add tests for the new API
68 #. Add a sample using the API
69 #. Update the documentation
74 Large changes to the Zephyr project must submit an :ref:`RFC proposal <rfcs>`
75 describing the full scope of change and future work. The RFC proposal provides
76 the required context to reviewers, but allows for smaller, incremental, PRs to
77 get reviewed and merged into the project. The RFC should also define the minimum
85 - Other large changes that can benefit from the RFC proposal process.
87 Maintainers have the discretion to request that contributors create an RFC for
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
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
112 be added to the automated test suite. All API functions should have test cases
113 and there should be tests for the behavior contracts of the API. Maintainers
114 and reviewers have the discretion to determine if the provided tests are
115 sufficient. The examples below demonstrate best practices on how to test APIs
119 provide around 85% test coverage for the
122 APIs. The :zephyr_file:`fuel gauge tests <tests/drivers/fuel_gauge/sbs_gauge>`
123 use the :zephyr_file:`smart battery emulator <drivers/fuel_gauge/sbs_gauge/emul_sbs_gauge.c>`,
124 providing test coverage for the
126 and the :zephyr_file:`smart battery driver <drivers/fuel_gauge/sbs_gauge/sbs_gauge.c>`.
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
130 next release detailing the change. APIs marked as experimental are excluded
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.
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
151 the greater picture.
153 - Respond to comments using the "Start Review" and "Add Review" green buttons in
154 the "Files changed" view. This allows responding to multiple comments and
155 publishing the responses in bulk. This reduces the number of emails sent to
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.
169 The Zephyr community is a diverse group of individuals, with different levels of
173 The `Zephyr Dev Meeting`_ performs a triage of PRs missing reviewer approval,
177 #. Identify PRs without any comments or reviews, ping the PR Assignee to start a
179 #. For PRs that have otherwise stalled, the Zephyr Dev Meeting pings the
180 Assignee and any reviewers that have left comments on the PR.
182 Contributors may request PRs to be reviewed outside of the Zephyr Dev Meeting
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`_
193 independent of the triage process. Not all contributors have the required
194 privileges to add labels to PRs, in this case the contributor should request
195 help on Discord or send an email to the `Zephyr devel mailing list`_.
209 defines the following escalation process for resolving technical disagreements.
211 Before escalation of technical disagreements, follow the steps below:
213 - Resolve in the PR among assignee, maintainers and reviewer.
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
224 stale, unrelated or irrelevant change requests by reviewers giving the
226 change requests or start the escalation process.
228 The assignee has the responsibility to document the reasoning for dismissing
229 any reviews in the PR and should notify the reviewer about their review being
232 To give the reviewers time to respond and escalate, the assignee is
233 expected to block the PR from being merged either by not
234 approving the PR or by setting the *DNM* label.
236 Escalation can be triggered by any party participating in the review
237 process (assignee, reviewers or the original author of the change) following
238 the steps below:
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
242 processed, the `Architecture Working Group`_ shall facilitate an offline
243 review of the escalation if requested, especially if any of the parties can't
244 attend the meeting.
247 to the TSC and get a binding resolution in the TSC by adding the *TSC* label
248 on the PR.
250 - The Assignee is expected to ensure the resolution of the escalation and the
251 outcome is documented in the related pull request or issues on Github.
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
273 bandwidth. As a reviewer, prioritize review requests in the following order:
275 #. PRs related to items in the `Zephyr Release Plan`_ or those targeting
276 the next release during the stabilization period (after RC1).
277 #. PRs where the reviewer has requested blocking changes.
278 #. PRs assigned to the reviewer as the area maintainer.
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
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,
298 reviewers should add suggestions as a comment to the :ref:`RFC <rfcs>`. This
300 to work on a feature once the minimum implementation has merged.
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
308 - Reviewers shall be *clear* and *concise* what changes they are requesting when the
309 "Request Changes" option is used. Requested changes shall be in the scope of
310 the PR in question and following the contribution and style guidelines of the
314 If requested changes cannot be resolved within the review process, the
316 path, which may include closing the PR.