Searched full:branch (Results 1 – 25 of 112) sorted by relevance
12345
| /Zephyr-latest/doc/project/ |
| D | code_flow.rst | 16 of new features to be introduced into the main branch when ready. Creating a new
17 collaboration branch requires a justification and TSC approval. Collaboration branches
18 shall be based off the main branch and any changes developed in the collab
19 branch shall target the main development branch. For released versions of
23 vx.y-branch
32 Changes submitted to a collaboration branch can evolve and improve
33 incrementally in a branch, before they are submitted to the mainline tree for
36 By dedicating an isolated branch to complex features, it's
41 has been completed. When a branch is requested, the proposal should include the
44 * Define exit criteria for merging the collaboration branch changes back into the main branch.
[all …]
|
| D | index.rst | 47 - subsystem/feature branch: is a branch within the same repository. In our case,
48 we will use the term branch also when referencing branches not in the same
50 - upstream: A parent branch the source code is based on. This is the branch you
|
| D | release_process.rst | 21 - linear mode on main branch,
59 main branch is said to be open for development. At that time, code which is deemed to be
206 - v[Major].[Minor].99 - A tag applied to main branch to signify that work on
210 work-in-progress main branch version. Presence of this tag allows generation of
211 sensible output for "git describe" on main branch, as typically used for
230 products and the auditable branch used for certification.
339 Changes and fixes flow in both directions. However, changes from main branch to an
340 LTS branch will be limited to fixes that apply to both branches and for existing
343 All fixes for an LTS branch that apply to the mainline tree shall be submitted to
351 auditable code bases shall be kept in sync after the audit branch is created,
[all …]
|
| /Zephyr-latest/doc/services/device_mgmt/ |
| D | mcumgr_backporting.rst | 25 As such, there are four possible ways to apply a change to the 2.7 branch:
27 … done directly to the Zephyr held code of the MCUmgr library, is backported to the ``v2.7-branch``.
28 … ported to the Zephyr held code from the upstream repository, is backported to the ``v2.7-branch``.
30 to the ``v2.7-branch``.
32 directly applied to the ``v2.7-branch``.
56 You must also apply the ``backport v2.7-branch`` label to the bug report.
84 #. Create the pull request selecting ``v2.7-branch`` as the merge target.
95 1. Create the pull request selecting ``v2.7-branch`` as the merge target.
126 Both cases are similar and differ only in the branch name.
131 1. Create a branch named as follow:
[all …]
|
| /Zephyr-latest/include/zephyr/drivers/clock_control/ |
| D | clock_control_silabs.h | 28 uint8_t branch; member
34 .branch = DT_CLOCKS_CELL(node_id, branch), \
40 .branch = DT_INST_CLOCKS_CELL(inst, branch), \
|
| /Zephyr-latest/doc/contribute/ |
| D | modifying_contributions.rst | 11 to Zephyr's main branch as part of the original pull requests. The authors
23 * get content merged to the project's main branch as part of a larger
26 * a developer pushes to a branch or pull request opened by another
30 to the project's main branch
45 A developer who intends to force-push to a branch or pull request of
70 inside their original branch or pull request, by other Zephyr developers.
|
| /Zephyr-latest/tests/drivers/clock_control/clock_control_api/src/ |
| D | silabs_device_subsys.h | 12 .branch = CLOCK_BRANCH_LSPCLK,
17 .branch = CLOCK_BRANCH_WDOG0CLK,
|
| /Zephyr-latest/tests/subsys/llext/src/ |
| D | riscv_edge_case_cb_type.c | 9 * Immediates in branch/jump-type instructions are signed-extended.
12 * A compressed branch (cb-type) instruction is used to trigger the edge case.
|
| /Zephyr-latest/.github/workflows/ |
| D | scorecards.yml | 7 # For Branch-Protection check. Only the default branch is supported. See
8 # https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection
|
| D | pylib_tests.yml | 10 - v*-branch
17 - v*-branch
|
| D | twister-publish.yaml | 46 --run-branch ${{github.ref_name}} \
51 --run-branch ${{github.ref_name}} \
|
| D | twister_tests.yml | 10 - v*-branch
21 - v*-branch
|
| D | scripts_tests.yml | 10 - v*-branch
17 - v*-branch
|
| D | devicetree_checks.yml | 11 - v*-branch
18 - v*-branch
|
| D | west_cmds.yml | 10 - v*-branch
19 - v*-branch
|
| D | hello_world_multiplatform.yaml | 7 - v*-branch
12 - v*-branch
|
| /Zephyr-latest/scripts/release/ |
| D | list_backports.py | 6 """Query issues in a release branch
9 branch in order to simplify tracking changes such as automated backports,
22 -b v2.7-branch \
29 -b v3.0-branch \
63 … help='branch (base) for PRs (e.g. v2.7-branch)', metavar='BRANCH', required=True)
325 'Please ensure the body of each PR to a release branch contains "Fixes #1234"')
|
| /Zephyr-latest/soc/nordic/ |
| D | Kconfig | 122 firmware branch state of the APPROTECT mechanism from UICR, so if
129 the firmware branch of the APPROTECT mechanism, preventing it
163 firmware branch state of the secure APPROTECT mechanism from UICR,
171 firmware branch of the secure APPROTECT mechanism, preventing it
|
| /Zephyr-latest/doc/develop/west/ |
| D | workspaces.rst | 11 The ``manifest-rev`` branch
14 West creates and controls a Git branch named ``manifest-rev`` in each
15 project. This branch points to the revision that the manifest file
19 purposes, the ``manifest-rev`` branch allows the manifest file to use SHAs
22 Although ``manifest-rev`` is a normal Git branch, west will recreate and/or
25 you manually add to this branch may be lost the next time you run ``west
26 update``. Instead, check out a local branch with another name, and either
32 West does not create a ``manifest-rev`` branch in the manifest repository,
51 when a project's ``manifest-rev`` branch must be updated to a newly fetched
|
| D | built-in.rst | 57 the default branch in the manifest repository unless the ``--mr`` option
111 #. Sets the project's :ref:`manifest-rev <west-manifest-rev>` branch to the
129 if the project is tracking a branch), ``west update`` always fetches,
132 Some branch names might look like short SHAs, like ``deadbeef``. West treats
143 behind some commits which are no longer referred to by any branch. These
146 branch checked out before running ``west update``.
158 between your branch and new commits brought in by the manifest. You
170 - in projects where your branch diverged from the incoming commits, it
|
| /Zephyr-latest/dts/bindings/clock/ |
| D | silabs,series-clock.yaml | 19 - branch
|
| /Zephyr-latest/soc/renesas/rcar/rcar_gen3/r7/ |
| D | soc.c | 17 /* Invalidate instruction cache and flush branch target cache */ in soc_reset_hook()
|
| /Zephyr-latest/doc/safety/ |
| D | safety_overview.rst | 277 #. On the main branch, the safety scope of the project should be identified, which typically
295 There is still a path from the main branch to this area. This is needed in case a serious bug or
296 important change is found or implemented on the main branch in the safety scope, after the LTS
297 and the auditable branch were created. In this case, the Safety Committee, together with the
299 so that the bug fix or change could also be integrated into the auditable branch. This
309 #. This transition from the auditable branch to the main branch should only occur in exceptional
311 that needs to be quickly adapted on the “auditable” branch in order to obtain certification. In
313 a path to merge these changes back into the main branch so that they are not lost, and to have
|
| /Zephyr-latest/drivers/w1/ |
| D | w1_net.c | 41 * their own addresses' bit. This allows the master to branch through 64-bit
107 * We can stop following the branch. in search_slave()
115 * We can directly follow last_id_bit branch. in search_slave()
127 * Start always w/ branch of 1s in search_slave()
129 * Follow same branch as before in search_slave()
138 * Follow same branch as before in search_slave()
|
| /Zephyr-latest/submanifests/ |
| D | example.yaml.sample | 12 # branch, change the 'revision' line accordingly.
|
12345
