Searched refs:changes (Results 1 – 25 of 191) sorted by relevance
12345678
/Zephyr-latest/doc/project/ |
D | code_flow.rst | 18 shall be based off the main branch and any changes developed in the collab 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 | 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 82 Trivial changes are those that appear obvious enough and do not require maintainer or code-owner 83 involvement. Such changes should not change the logic or the design of a 86 - Documentation changes 87 - Configuration changes [all …]
|
D | project_roles.rst | 72 and requested changes should still be considered by the pull request author. 89 * Responsibility to review relevant code changes within reasonable time. 101 be addressed by the original submitter. In cases where the changes requested do 173 * Right to block pull requests from being merged until issues or changes 215 * Right to merge code changes to the zephyr tree following the project rules. 216 * Right to revert any changes that have broken the code base 217 * Right to close any stale changes after <N> months of no activity 262 verify changes either directly or through QA before major 263 changes and major milestones. 313 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/subsys/bluetooth/audio/ |
D | Kconfig.pacs | 20 PAC Characteristic changes. 40 Audio Location Characteristic changes. 55 PAC Characteristic changes. 75 Audio Location Characteristic changes. 87 Supported Audio Contexts Characteristic changes.
|
/Zephyr-latest/scripts/release/ |
D | list_devicetree_bindings_changes.py | 165 for binding, changes in binding2changes.items(): 166 ret[get_vnd(binding.compatible)][binding] = changes 408 def print_changes(self, changes: Changes): 409 for vnd in changes.vnds: 416 added = changes.vnd2added[vnd] 424 removed = changes.vnd2removed[vnd] 432 modified = changes.vnd2changes[vnd] 447 for binding, changes in binding2changes.items(): 450 for change in changes: 524 changes = get_changes_between(compat2binding_start, [all …]
|
/Zephyr-latest/doc/contribute/ |
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. 36 Some changes do not require an RFC:
|
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: 74 Large changes to the Zephyr project must submit an :ref:`RFC proposal <rfcs>` 84 - :ref:`treewide-changes`. 85 - Other large changes that can benefit from the RFC proposal process. 96 - The PR description must include a summary of the changes and their rationales. 129 - Incompatible changes to APIs must also update the release notes for the [all …]
|
D | guidelines.rst | 8 standards and methods for submitting changes help reduce the chaos that can result 162 - If you've pushed your changes to GitHub already you'll need to force push 324 similar ideas for changes or additions. Send a message to the `Zephyr devel 370 repository. Use the search filters and labels to locate PRs related to changes 427 * ``doc: ...`` for documentation changes 428 * ``drivers: foo:`` for ``foo`` driver changes 429 * ``Bluetooth: Shell:`` for changes to the Bluetooth shell 430 * ``net: ethernet:`` for Ethernet-related networking changes 431 * ``dts:`` for treewide devicetree changes 432 * ``style:`` for code style changes [all …]
|
/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/doc/releases/ |
D | index.rst | 73 Release notes contain a list of changes that have been made to the different 94 As mentioned in the previous section, changes in the code that require an action 99 - Breaking API changes 101 - Devicetree or Kconfig changes that affect the user (changes to defaults, 103 - Treewide changes that have an effect (e.g. changing the include path or
|
/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 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 155 Pull Request containing those changes in code form. [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.
|
/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/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/drivers/sensor/bosch/bmp180/ |
D | Kconfig | 17 Enable runtime changes of the oversampling value
|
/Zephyr-latest/samples/drivers/memc/boards/ |
D | rd_rw612_bga.overlay | 37 /* Override pin control state to use one that only changes the PSRAM pin
|
D | frdm_rw612.overlay | 45 /* Override pin control state to use one that only changes the PSRAM pin
|
/Zephyr-latest/soc/intel/intel_adsp/ace/ |
D | Kconfig.defconfig.ace30 | 27 # else we will be chasing changes all the time.
|
/Zephyr-latest/tests/drivers/i2s/i2s_speed/ |
D | Readme.txt | 8 signals externally on the EVK. These are the HW changes required to run this test:
|
/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,
|
/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/drivers/eeprom/ |
D | Kconfig.eeprom_emu | 13 larger than the EEPROM area and by storing only changes to the EEPROM
|
/Zephyr-latest/doc/services/tfm/ |
D | testsuites.rst | 41 changes to TF-M, such as enabling a new TF-M board target, or making changes
|
/Zephyr-latest/doc/develop/ |
D | modules.rst | 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, 251 * changes required due to updates in the zephyr main tree [all …]
|
12345678