Searched full:review (Results 1 – 25 of 53) sorted by relevance
123
| /Zephyr-latest/.github/workflows/ |
| D | do_not_merge.yml | 15 contains(github.event.*.labels.*.name, 'Architecture Review') ||
16 contains(github.event.*.labels.*.name, 'dev-review') }}
18 echo "Pull request is labeled as 'DNM', 'TSC', 'Architecture Review' or 'dev-review'."
|
| D | greet_first_time_contributor.yml | 37 If you haven't already, please make sure to review the project's [Contributor
42 …ally, you can [escalate the review](https://docs.zephyrproject.org/latest/contribute/contributor_e…
|
| /Zephyr-latest/doc/project/ |
| D | dev_env_and_tools.rst | 6 Code Review
31 Give reviewers time to review before code merge
36 changes are proposed using pull request, we need to allow for a minimal review
37 time to give developers and contributors the opportunity to review and comment
42 code-owner review. Additionally, some changes might require further discussions
44 the diagram below proposes minimal review times for each category:
75 on the fix, severity, and availability of someone to review them (other than the
76 author) they can be merged with justification without review by one of the
129 Pull Request should not be merged by author without review
133 without a review. The following exceptions apply:
[all …]
|
| D | modifying_contributions.rst | 13 following the review process.
43 * invite the original author of the patches to their pull request review.
48 is done to drive the pull request review to completion, when the pull
|
| D | index.rst | 27 community members work together to review these Issues and PRs, managing
36 and specifics about :ref:`review timelines <review_time>` to learn about the
|
| D | project_roles.rst | 49 discussions and in the review of contributions.
89 * Responsibility to review relevant code changes within reasonable time.
104 assignee to advance the review process and resolve any disagreements.
233 periodically review the team’s followed processes,
316 should come in as standalone pull requests and require TSC review.
317 * If additional review by the TSC is required, the maintainers of the file
321 * Path, collaborator and name changes do not require a review by the TSC.
322 * Addition of new areas without a maintainer do not require review by the TSC.
361 same organisation as the approvers. To allow for project wide review and
376 organisation. In such cases, the minimum review period of at least 2 days
[all …]
|
| D | code_flow.rst | 57 - Review changes coming from team members and request review from branch owners
|
| /Zephyr-latest/doc/contribute/ |
| D | contributor_expectations.rst | 11 to set aside a few minutes to review smaller changes several times than it is
12 to allocate large blocks of time to review a large PR.
25 Draft PRs have no review expectation and PRs created as drafts from the start
153 - Respond to comments using the "Start Review" and "Add Review" green buttons in
159 middle of a review. If a rebase is required, push this as a separate update
178 review or assign to a different maintainer.
191 - After 2 weeks of inactivity, add the `dev-review`_ label to the PR. This
229 any reviews in the PR and should notify the reviewer about their review being
236 Escalation can be triggered by any party participating in the review
241 Review` label on the PR. Beside the weekly meeting where such escalations are
[all …]
|
| D | guidelines.rst | 65 this contributing and review process for imported components.
330 triage team will review and comment on the submission, typically within a few
367 compliance with Zephyr standards and facilitate the review process.
645 GitHub PR page, below the review status. Depending on the success or failure
755 controlled changes. This practice simplifies review, makes merging and
845 #. Review the pull request changes, and verify that you are opening a pull
854 review. Email will be sent as review comments are made, or you can check
874 commit(s) to fix review issues. In your development repo::
881 issues in the review.
907 .. note:: While amending commits and force pushing is a common review model
[all …]
|
| D | external.rst | 159 Submission and review process
193 early submission process to the Zephyr governing board for further review
195 #. The Zephyr governing board has two weeks to review and ask questions:
|
| /Zephyr-latest/doc/security/ |
| D | reporting.rst | 37 Review [shape = box];
45 Assigned -> Review [dir = both];
46 Review -> Accepted;
47 Review -> Rejected;
66 - Review: Once there is a Zephyr pull request for the issue, the PR
68 the Review state.
94 The Zephyr Security Subcommittee shall review the reported
96 attendance. During this review, they shall determine if new issues
|
| D | secure-coding.rst | 41 should have. This knowledge will be necessary for the review process
44 Following this is a description of the review process used to
236 Code Review
239 The Zephyr project shall use a code review system that all changes are
245 secure designer to also review the code. Any of these individuals
272 Zephyr Security Subcommittee. This review should focus on
276 the review team should avoid unnecessary delay in lifting issues that
|
| D | security-overview.rst | 83 2. The Zephyr Security Subcommittee will review these changes and provide feedback
162 maintainer. The main goals of the code review are:
366 the code review. These coding conventions are enforced by
405 - **Automation:** the review process and checks for coding rule
409 in from subsystems, in addition to review process and coding rule
|
| /Zephyr-latest/scripts/ci/stats/ |
| D | merged_prs.py | 52 for review in reviews:
54 if review.user and review.state == 'APPROVED':
55 reviewers.add(review.user.login)
78 # if a PR was made ready for review from draft, calculate based on when it
84 # calculate time the PR was in review, hours and business days.
|
| /Zephyr-latest/samples/subsys/llext/modules/ |
| D | Kconfig | 21 required if you select 'm'. Please review this sample's documentation
|
| /Zephyr-latest/doc/develop/manifest/ |
| D | index.rst | 9 this contributing and review process for imported components.
|
| /Zephyr-latest/scripts/utils/ |
| D | migrate_sys_init.py | 6 Review the output carefully! This script may not cover all cases!
|
| /Zephyr-latest/tests/lib/cmsis_dsp/common/ |
| D | math_helper.h | 23 * Production release and review comments incorporated.
26 * Production release and review comments incorporated.
|
| /Zephyr-latest/tests/subsys/random/rng/src/ |
| D | main.c | 53 * Based on review comments in in ZTEST()
|
| /Zephyr-latest/doc/develop/api/ |
| D | api_lifecycle.rst | 50 peripheral or driver subsystem, review of the API is enforced and is driven by
189 - The label ``Architecture Review`` if the RFC was not yet discussed and agreed upon in `Zephyr
|
| /Zephyr-latest/doc/develop/west/ |
| D | why.rst | 52 - Assumes Gerrit is used for code review
|
| /Zephyr-latest/scripts/ |
| D | set_assignees.py | 169 for review in revs:
170 existing_reviewers.add(review.user)
|
| D | coccicheck | 125 echo 'When using "patch" mode, carefully review the patch before submitting it.'
|
| /Zephyr-latest/doc/hardware/peripherals/ |
| D | rtc.rst | 78 console to be manually compared. The user must review the set and
|
| /Zephyr-latest/doc/services/device_mgmt/ |
| D | mcumgr_backporting.rst | 128 To merge a backported fix after the pull request for the fix has gone through the review process,
|
123
