| /Zephyr-Core-3.4.0/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
35 changes are proposed using pull request, we need to allow for a minimal review
37 on changes. There are different categories of changes and we know that some
38 changes do require reviews by subject matter experts and owners of the subsystem
39 being changed. Many changes fall under the "trivial" category that can be
41 code-owner review. Additionally, some changes might require further discussions
58 changes can change the label of a pull request by adding a comment justifying
61 - Changes should not be merged before the minimal time has expired.
81 Trivial changes are those that appear obvious enough and do not require maintainer or code-owner
82 involvement. Such changes should not change the logic or the design of a
[all …]
|
| D | project_roles.rst | 71 merging a pull request. However, Contributors comments and requested changes
87 * Responsibility to review relevant code changes within reasonable time.
176 * Right to merge code changes to the zephyr tree following the project rules.
177 * Right to revert any changes that have broken the code base
178 * Right to close any stale changes after <N> months of no activity
223 verify changes either directly or through QA before major
224 changes and major milestones.
277 in a standalone commit alongside other changes introducing new files and
279 * Major changes to the file, including the addition of new areas with new maintainers
282 should send the requested changes to the TSC and give members of the TSC two
[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-Core-3.4.0/doc/develop/api/ |
| D | api_lifecycle.rst | 58 Changes will not be announced.
76 minor changes. Backwards-compatibility will be maintained if reasonable.
89 #. A Pull Request must be opened that changes the corresponding entry in the
99 Introducing incompatible changes
127 - Function call changes
128 - Device Tree changes (source and bindings)
129 - Kconfig option changes
134 Instead of a written description of the changes, the RFC issue may link to a
135 Pull Request containing those changes in code form.
155 - The actual changes to the API
[all …]
|
| /Zephyr-Core-3.4.0/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-Core-3.4.0/doc/contribute/ |
| D | contributor_expectations.rst | 10 changes as smaller pull requests. Smaller pull requests (PRs) have the following
14 to set aside a few minutes to review smaller changes several times than it is
21 changes in the tree.
45 - Modifying a feature, especially for API behavior contract changes.
65 the PR into multiple commits targeting these specific changes:
74 Large Changes
77 Large changes to the Zephyr project must submit an :ref:`RFC proposal <rfcs>`
83 Changes which require an RFC proposal include:
87 - :ref:`treewide-changes`.
88 - Other large changes that can benefit from the RFC proposal process.
[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.
36 Some changes do not require an RFC:
|
| D | guidelines.rst | 8 standards and methods for submitting changes help reduce the chaos that can result
160 - If you've pushed your changes to GitHub already you'll need to force push
322 similar ideas for changes or additions. Send a message to the `Zephyr devel
384 To verify that your changes did not break any tests or samples, please run the
415 In case of major changes to the kernel, build or configuration infrastructures
416 of Zephyr, it is advised to use twister for verifying majority the changes
558 controlled changes. This practice simplifies review, makes merging and
563 and test your changes thoroughly before submitting.
614 #. Make changes, test locally, change, test, test again, ... (Check out the
626 #. Verify changes to be committed look as you expected::
[all …]
|
| /Zephyr-Core-3.4.0/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-Core-3.4.0/doc/develop/west/ |
| D | release-notes.rst | 9 Major changes:
24 Other changes:
39 API changes:
47 Major changes:
64 Major changes in this release:
66 - The :ref:`west-apis` are now declared stable. Any breaking changes will be
82 Other changes:
97 API changes:
147 API changes:
191 :ref:`API <west-apis>` changes:
[all …]
|
| /Zephyr-Core-3.4.0/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-Core-3.4.0/subsys/usb/device/class/ |
| D | Kconfig.cdc | 48 bool "Support callbacks when the USB host changes the virtual baud rate"
52 remote host changes the virtual baud rate. This is used
|
| /Zephyr-Core-3.4.0/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-Core-3.4.0/subsys/net/lib/lwm2m/ |
| D | README_lwm2m | 23 …attempt to use the 3-way merge capabilities by committing the un-patched changes (i.e. up to and i…
29 The patch was created by, committing the unpatched changes, then committing the desired patches in …
|
| /Zephyr-Core-3.4.0/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-Core-3.4.0/doc/services/tfm/ |
| D | testsuites.rst | 41 changes to TF-M, such as enabling a new TF-M board target, or making changes
|
| /Zephyr-Core-3.4.0/samples/application_development/sysbuild/with_mcuboot/sysbuild/ |
| D | mcuboot.conf | 1 # Example of sample specific Kconfig changes when building sample with MCUboot
|
| /Zephyr-Core-3.4.0/drivers/pinctrl/ |
| D | Kconfig.gecko | 3 # TODO: copyright changes?
|
| /Zephyr-Core-3.4.0/samples/net/lwm2m_client/ |
| D | overlay-dtls.conf | 8 # Special MbedTLS changes
|
| /Zephyr-Core-3.4.0/drivers/eeprom/ |
| D | Kconfig.eeprom_emu | 13 larger than the EEPROM area and by storing only changes to the EEPROM
|
| /Zephyr-Core-3.4.0/include/zephyr/drivers/misc/ft8xx/ |
| D | ft8xx.h | 87 * This function configures FT8xx to trigger interrupt when touch event changes
90 * When touch event changes tag value, FT8xx activates INT line. The line is
|
| /Zephyr-Core-3.4.0/tests/bsim/bluetooth/mesh/tests_scripts/priv_beacon/ |
| D | priv_beacon_adv.sh | 8 # Test Random value changes for different Random intervals (10s, 0 - on every beacon, 30s).
|
| /Zephyr-Core-3.4.0/boards/arm/nrf9160dk_nrf9160/dts/bindings/ |
| D | nordic,nrf9160dk-nrf52840-reset.yaml | 5 # Any changes should be done in both instances.
|
| /Zephyr-Core-3.4.0/boards/arm/nrf9160dk_nrf52840/dts/bindings/ |
| D | nordic,nrf9160dk-nrf52840-reset.yaml | 5 # Any changes should be done in both instances.
|
