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
95 - Each commit in the PR must provide a commit message following the
101 - The PR description must include a summary of the changes and their rationales.
103 - All files in the PR must comply with :ref:`Licensing
106 - The code must follow the Zephyr :ref:`coding_style` and :ref:`coding_guidelines`.
108 - The PR must pass all CI checks, as described in :ref:`merge_criteria`.
113 and maintain bisectability. The following guidelines expand on this principle:
119 different types of changes (e.g., feature implementation and unrelated refactoring) in the same
124 Every commit in the pull request must build successfully and pass all relevant tests. This
125 ensures that git bisect can be used effectively to identify the specific commit that introduced
131 … temporary files, or debugging code). These should be squashed or rewritten before submitting the
139 Use interactive rebasing (git rebase -i) to clean up the commit history before submitting the
149 earlier commits to reflect the final structure. This ensures that:
151 * The history remains clean and easy to follow.
156 While cleaning up the commit history, ensure that authorship attribution remains accurate.
160 The final commit history should be easy to understand for future maintainers. Logical units of
161 change should be grouped into commits that tell a clear, coherent story of the work done.
163 - When major new functionality is added, tests for the new functionality shall
164 be added to the automated test suite. All API functions should have test cases
165 and there should be tests for the behavior contracts of the API. Maintainers
166 and reviewers have the discretion to determine if the provided tests are
167 sufficient. The examples below demonstrate best practices on how to test APIs
171 provide around 85% test coverage for the
174 APIs. The :zephyr_file:`fuel gauge tests <tests/drivers/fuel_gauge/sbs_gauge>`
175 use the :zephyr_file:`smart battery emulator <drivers/fuel_gauge/sbs_gauge/emul_sbs_gauge.c>`,
176 providing test coverage for the
178 and the :zephyr_file:`smart battery driver <drivers/fuel_gauge/sbs_gauge/sbs_gauge.c>`.
179 - Code coverage reports for the Zephyr project are available on `Codecov`_.
181 - Incompatible changes to APIs must also update the release notes for the
182 next release detailing the change. APIs marked as experimental are excluded
185 - Changes to APIs must increment the API version number according to the API
188 - Documentation must be added and/or updated to reflect the changes in the code
189 introduced by the PR. The documentation changes must use the proper
190 terminology as present in the existing pages, and must be written in American
191 English. If you include images as part of the documentation, those must follow
192 the rules in :ref:`doc_images`. Please refer to :ref:`doc_guidelines` for
195 - PRs must also satisfy all :ref:`merge_criteria` before a member of the release
196 engineering team merges the PR into the zephyr tree.
206 - Unless they applied the reviewer's recommendation exactly, authors must not
207 resolve and hide comments, they must let the initial reviewer do it. The
210 the greater picture.
212 - Respond to comments using the "Start Review" and "Add Review" green buttons in
213 the "Files changed" view. This allows responding to multiple comments and
214 publishing the responses in bulk. This reduces the number of emails sent to
217 - As GitHub does not implement |git range-diff|_, try to minimize rebases in the
219 with no other changes since the last push of the PR. When pushing a rebase
220 only, add a comment to the PR indicating which commit is the rebase.
228 The Zephyr community is a diverse group of individuals, with different levels of
232 The `Zephyr Dev Meeting`_ performs a triage of PRs missing reviewer approval,
236 #. Identify PRs without any comments or reviews, ping the PR Assignee to start a
238 #. For PRs that have otherwise stalled, the Zephyr Dev Meeting pings the
239 Assignee and any reviewers that have left comments on the PR.
241 Contributors may request PRs to be reviewed outside of the Zephyr Dev Meeting
244 - After 1 week of inactivity, ping the Assignee or reviewers on the PR by adding
245 a comment to the PR.
247 - After 2 weeks of inactivity, post a message on the `#pr-help`_ channel on
248 Discord linking to the PR.
250 - After 2 weeks of inactivity, add the `dev-review`_ label to the PR. This
251 explicitly adds the PR to the agenda for the next `Zephyr Dev Meeting`_
252 independent of the triage process. Not all contributors have the required
253 privileges to add labels to PRs, in this case the contributor should request
254 help on Discord or send an email to the `Zephyr devel mailing list`_.
268 defines the following escalation process for resolving technical disagreements.
270 Before escalation of technical disagreements, follow the steps below:
272 - Resolve in the PR among assignee, maintainers and reviewer.
276 - Optionally resolve in the next `Zephyr Dev Meeting`_ meeting with more
279 - The involved parties and the Assignee to be present when the issue is
282 - If no progress is made, the assignee (maintainer) has the right to dismiss
283 stale, unrelated or irrelevant change requests by reviewers giving the
285 change requests or start the escalation process.
287 The assignee has the responsibility to document the reasoning for dismissing
288 any reviews in the PR and should notify the reviewer about their review being
291 To give the reviewers time to respond and escalate, the assignee is
292 expected to block the PR from being merged either by not
293 approving the PR or by setting the *DNM* label.
295 Escalation can be triggered by any party participating in the review
296 process (assignee, reviewers or the original author of the change) following
297 the steps below:
299 - Escalate to the `Architecture Working Group`_ by adding the `Architecture
300 Review` label on the PR. Beside the weekly meeting where such escalations are
301 processed, the `Architecture Working Group`_ shall facilitate an offline
302 review of the escalation if requested, especially if any of the parties can't
303 attend the meeting.
306 to the TSC and get a binding resolution in the TSC by adding the *TSC* label
307 on the PR.
309 - The Assignee is expected to ensure the resolution of the escalation and the
310 outcome is documented in the related pull request or issues on Github.