| /Zephyr-latest/doc/contribute/ |
| D | reviewer_expectations.rst | 14 #. PRs where the reviewer has requested blocking changes.
29 - Code style changes that impact the readability of the PR.
30 - Reviewing commits separately when the requested changes cascade into the
39 - When using the "Request Changes" option, mark trivial, non-functional,
41 only non-blocking changes remain. The PR author has discretion as to whether
45 - Style changes that the reviewer disagrees with but that are not documented as
47 a reason for a request for changes. The reviewer can optionally correct any
51 - Whenever requesting style related changes, reviewers should be able to point
53 documentation. This does not apply to certain types of requests for changes,
54 notably those specific to the changes being submitted (e.g. the use of a
[all …]
|
| D | proposals_and_rfcs.rst | 6 Many changes, including bug fixes and documentation improvements can be
9 Many changes however are "substantial" and need to go through a
16 they intend to make "substantial" changes to Zephyr or its documentation. Some
24 include code changes to Zephyr itself.
48 Some changes or contributions do not require an RFC, the rationale and details
49 of the changes should however be part of the pull-request:
|
| D | contributor_expectations.rst | 7 changes as smaller pull requests. Smaller pull requests (PRs) have the following
11 to set aside a few minutes to review smaller changes several times than it is
18 changes in the tree.
42 - Modifying a feature, especially for API behavior contract changes.
62 the PR into multiple commits targeting these specific changes:
71 Large Changes
74 Large changes to the Zephyr project must submit an :ref:`RFC proposal <rfcs>`
80 Changes which require an RFC proposal include:
84 - :ref:`treewide-changes`.
85 - Other large changes that can benefit from the RFC proposal process.
[all …]
|
| D | guidelines.rst | 8 standards and methods for submitting changes help reduce the chaos that can result
309 similar ideas for changes or additions. Send a message to the `Zephyr devel
355 repository. Use the search filters and labels to locate PRs related to changes
363 Changes are submitted as Git commits. Each commit has a *commit
407 * ``doc: ...`` for documentation changes
408 * ``drivers: foo:`` for ``foo`` driver changes
409 * ``Bluetooth: Shell:`` for changes to the Bluetooth shell
410 * ``net: ethernet:`` for Ethernet-related networking changes
411 * ``dts:`` for treewide devicetree changes
412 * ``style:`` for code style changes
[all …]
|
| /Zephyr-latest/doc/project/ |
| D | code_flow.rst | 18 shall be based off the main branch and any changes developed in the collab
32 Changes submitted to a collaboration branch can evolve and improve
44 * Define exit criteria for merging the collaboration branch changes back into the main branch.
55 - All changes to collaboration branches shall come in form of github pull requests.
57 - Review changes coming from team members and request review from branch owners
58 when submitting changes.
60 - Push changes frequently to upstream using the following methods:
64 - Merge requests: When a set of changes has been done in a local branch and
|
| D | dev_env_and_tools.rst | 10 is accepted into the code base. Changes, in the form of Pull Requests (PR) are
36 changes are proposed using pull request, we need to allow for a minimal review
38 on changes. There are different categories of changes and we know that some
39 changes do require reviews by subject matter experts and owners of the subsystem
40 being changed. Many changes fall under the "trivial" category that can be
42 code-owner review. Additionally, some changes might require further discussions
59 changes can change the label of a pull request by adding a comment justifying
62 - Changes should not be merged before the minimal time has expired.
78 Trivial changes are those that appear obvious enough and do not require maintainer or code-owner
79 involvement. Such changes should not change the logic or the design of a
[all …]
|
| D | project_roles.rst | 72 and requested changes should still be considered by the pull request author.
99 * Responsibility to review relevant code changes within reasonable time.
111 be addressed by the original submitter. In cases where the changes requested do
183 * Right to block pull requests from being merged until issues or changes
225 * Right to merge code changes to the zephyr tree following the project rules.
226 * Right to revert any changes that have broken the code base
227 * Right to close any stale changes after <N> months of no activity
272 verify changes either directly or through QA before major
273 changes and major milestones.
323 in a standalone commit alongside other changes introducing new files and
[all …]
|
| D | issues.rst | 6 To maintain traceability and relation between proposals, changes, features, and
9 Any changes that originate from a tracked feature or issue should contain a
|
| /Zephyr-latest/doc/develop/api/ |
| D | api_lifecycle.rst | 65 When the API changes status to unstable API, mark the API version in the headers
71 Changes will not be announced.
91 minor changes. Backwards-compatibility will be maintained if reasonable.
104 #. A Pull Request must be opened that changes the corresponding entry in the
113 When the API changes status to stable API, mark the API version in the headers
119 Introducing breaking API changes
147 - Function call changes
148 - Device Tree changes (source and bindings)
149 - Kconfig option changes
154 Instead of a written description of the changes, the RFC issue may link to a
[all …]
|
| D | overview.rst | 7 current :ref:`stability level <api_lifecycle>`. More details about API changes
23 changes.
37 introduced within the private code. It MAY include patch level changes.
51 Changes to APIs in the future will require adapting the version following the
|
| /Zephyr-latest/subsys/bluetooth/audio/ |
| D | Kconfig.pacs | 22 PAC Characteristic changes.
42 Audio Location Characteristic changes.
58 PAC Characteristic changes.
78 Audio Location Characteristic changes.
90 Supported Audio Contexts Characteristic changes.
|
| /Zephyr-latest/scripts/checkpatch/ |
| D | timestamp | 14 # where: -a changes default to: 2015-01-14-18-11-56
15 # -d changes default to: 20150114
16 # -u changes default to: 20150114_181201
17 # -s changes default to: 20150114-1812.04
18 # -S changes default to: 20150114-1812
|
| /Zephyr-latest/scripts/release/ |
| D | list_devicetree_bindings_changes.py | 18 # TODO: include changes to child bindings
43 below for concrete changes.
50 class Changes: class
51 '''Container for all the changes that happened between the
117 ) -> Changes:
141 return Changes(vnds=sorted(vnds_set),
165 for binding, changes in binding2changes.items():
166 ret[get_vnd(binding.compatible)][binding] = changes
201 '''Enumerate the changes to a binding given its start and end values.'''
408 def print_changes(self, changes: Changes): argument
[all …]
|
| /Zephyr-latest/tests/drivers/i2s/i2s_speed/ |
| D | Readme.txt | 9 These are the HW changes required to run this test:
17 These are the HW changes required to run this test:
24 signals externally on the EVK. These are the HW changes required to run this test:
31 These are the HW changes required to run this test on MIMXRT1060-EVK[B/C]:
|
| /Zephyr-latest/subsys/fs/ext2/ |
| D | ext2_diskops.h | 110 * @brief Commit changes made to inode structure
112 * The changes are committed only to the cached block. They are truly written to
123 * @brief Commit changes made to inode block
125 * The changes are committed only to the cached block. They are truly written to
136 * @brief Commit changes made to superblock structure.
138 * The changes made to program structure are copied to disk representation and written to the
149 * @brief Commit changes made to block group structure.
151 * The changes made to program structure are copied to disk representation and written to the
|
| /Zephyr-latest/doc/develop/west/ |
| D | release-notes.rst | 9 Major changes:
46 Other changes:
61 API changes:
84 Major changes:
99 Other changes:
114 API changes:
122 Major changes:
139 Major changes in this release:
141 - The :ref:`west-apis` are now declared stable. Any breaking changes will be
157 Other changes:
[all …]
|
| /Zephyr-latest/doc/releases/ |
| D | release-notes-4.2.rst | 14 No list of bugfixes, minor changes, those are already in the git log, this is
36 An overview of the changes required or recommended when migrating your application from Zephyr
39 The following sections provide detailed lists of changes by component.
48 API Changes
134 Other notable changes
138 Any more descriptive subsystem or driver changes. Do you really want to write
|
| D | index.rst | 82 Release notes contain a list of changes that have been made to the different
84 Changes that require the user to modify their own application to support the new
91 with the changes in the project.
107 As mentioned in the previous section, changes in the code that require an action
112 - Breaking API changes
114 - Devicetree or Kconfig changes that affect the user (changes to defaults,
116 - Treewide changes that have an effect (e.g. changing the include path or
|
| /Zephyr-latest/doc/connectivity/bluetooth/api/mesh/ |
| D | cfg.rst | 14 local constraints, such as low battery power or changes in topology. For these
18 Runtime configuration changes before the node is provisioned will not be stored
|
| /Zephyr-latest/include/zephyr/drivers/uart/ |
| D | cdc_acm.h | 25 * @brief A function that is called when the USB host changes the baud
37 * The callback is invoked when the USB host changes the baud rate.
|
| /Zephyr-latest/subsys/usb/device/class/ |
| D | Kconfig.cdc | 56 bool "Support callbacks when the USB host changes the virtual baud rate"
60 remote host changes the virtual baud rate. This is used
|
| /Zephyr-latest/subsys/net/lib/lwm2m/ |
| D | README_lwm2m | 24 …attempt to use the 3-way merge capabilities by committing the un-patched changes (i.e. up to and i…
30 The patch was created by, committing the unpatched changes, then committing the desired patches in …
|
| /Zephyr-latest/samples/subsys/lorawan/fuota/sysbuild/ |
| D | mcuboot.conf | 1 # Kconfig changes when building sample with MCUboot using sysbuild.
|
| /Zephyr-latest/doc/develop/ |
| D | modules.rst | 122 Changes to the main branch of a module repository, including synchronization
126 ensures that the incoming changes are always **reviewable**, and the
130 changes that are to be brought into the module repository.
146 Upstream changes brought as a single *snapshot* commit (manual diff) in a
162 Upstream changes brought in by performing a Git merge of the intended upstream
229 * the contributor of the original changes in Zephyr is required to submit
230 the corresponding changes that are required in module repositories, to
231 ensure that Zephyr CI on the pull request with the original changes, as
244 Contributing changes to modules
247 Submitting and merging changes directly to a module's codebase, that is,
[all …]
|
| /Zephyr-latest/doc/build/snippets/ |
| D | design.rst | 26 - **future-proof and backwards-compatible**: arbitrary future changes to the
30 - **applicable to purely "software" changes**: unlike the shields feature,
|
