Lines Matching +full:get +full:- +full:coverage +full:- +full:files
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.
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.
77 get reviewed and merged into the project. The RFC should also define the minimum
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.
95 - Each commit in the PR must provide a commit message following the
96 :ref:`commit-guidelines`.
98 - No fixup or merge commits are allowed, see :ref:`Contribution workflow` for
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`.
112 - Commits in a pull request should represent clear, logical units of change that are easy to review
117 Each commit should correspond to a self-contained, meaningful change. For example, adding a
128 3. Squash Intermediary or Non-Final Development History
131 … temporary files, or debugging code). These should be squashed or rewritten before submitting the
132 pull request. Remove non-final artifacts, such as:
134 * Temporary renaming of files that are later renamed again.
139 Use interactive rebasing (git rebase -i) to clean up the commit history before submitting the
148 … If files or code are renamed or rewritten in later commits during development, squash or rewrite
163 - When major new functionality is added, tests for the new functionality shall
170 - :zephyr_file:`Kernel timer tests <tests/kernel/timer/timer_behavior>`
171 provide around 85% test coverage for the
173 - Emulators for off-chip peripherals are an effective way to test driver
176 providing test coverage for the
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
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
195 - PRs must also satisfy all :ref:`merge_criteria` before a member of the release
201 .. _`Codecov`: https://app.codecov.io/gh/zephyrproject-rtos/zephyr
206 - Unless they applied the reviewer's recommendation exactly, authors must not
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
217 - As GitHub does not implement |git range-diff|_, try to minimize rebases in the
222 .. |git range-diff| replace:: ``git range-diff``
223 .. _`git range-diff`: https://git-scm.com/docs/git-range-diff
229 commitment and priorities. As such, reviewers and maintainers may not get to a
244 - After 1 week of inactivity, ping the Assignee or reviewers on the PR by adding
247 - After 2 weeks of inactivity, post a message on the `#pr-help`_ channel on
250 - After 2 weeks of inactivity, add the `dev-review`_ label to the PR. This
272 - Resolve in the PR among assignee, maintainers and reviewer.
274 - Assignee to act as moderator if applicable.
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
299 - Escalate to the `Architecture Working Group`_ by adding the `Architecture
305 - If all avenues of resolution and escalation have failed, assignees can escalate
306 to the TSC and get a binding resolution in the TSC by adding the *TSC* label
309 - The Assignee is expected to ensure the resolution of the escalation and the
312 .. _#pr-help: https://discord.com/channels/720317445772017664/997527108844798012
314 .. _dev-review: https://github.com/zephyrproject-rtos/zephyr/labels/dev-review
316 …ev Meeting: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups#…
318 .. _Architecture Project: https://github.com/zephyrproject-rtos/zephyr/projects/18
320 …hitecture Working Group: https://github.com/zephyrproject-rtos/zephyr/wiki/Architecture-Working-Gr…