diff options
Diffstat (limited to 'documentation')
-rw-r--r-- | documentation/bsp-guide/bsp.rst | 2 | ||||
-rw-r--r-- | documentation/contributor-guide/index.rst | 2 | ||||
-rw-r--r-- | documentation/contributor-guide/submit-changes.rst (renamed from documentation/contributor-guide/submit-change.rst) | 132 | ||||
-rw-r--r-- | documentation/dev-manual/debugging.rst | 2 | ||||
-rw-r--r-- | documentation/dev-manual/start.rst | 4 | ||||
-rw-r--r-- | documentation/dev-manual/vulnerabilities.rst | 2 | ||||
-rw-r--r-- | documentation/overview-manual/development-environment.rst | 6 |
7 files changed, 77 insertions, 73 deletions
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst index 52a07cfcb0..3be314bcf6 100644 --- a/documentation/bsp-guide/bsp.rst +++ b/documentation/bsp-guide/bsp.rst | |||
@@ -927,7 +927,7 @@ Yocto Project: | |||
927 | - The name and contact information for the BSP layer maintainer. | 927 | - The name and contact information for the BSP layer maintainer. |
928 | This is the person to whom patches and questions should be sent. | 928 | This is the person to whom patches and questions should be sent. |
929 | For information on how to find the right person, see the | 929 | For information on how to find the right person, see the |
930 | :doc:`../contributor-guide/submit-change` section in the Yocto Project and | 930 | :doc:`../contributor-guide/submit-changes` section in the Yocto Project and |
931 | OpenEmbedded Contributor Guide. | 931 | OpenEmbedded Contributor Guide. |
932 | 932 | ||
933 | - Instructions on how to build the BSP using the BSP layer. | 933 | - Instructions on how to build the BSP using the BSP layer. |
diff --git a/documentation/contributor-guide/index.rst b/documentation/contributor-guide/index.rst index 8fa65045a3..a832169455 100644 --- a/documentation/contributor-guide/index.rst +++ b/documentation/contributor-guide/index.rst | |||
@@ -21,6 +21,6 @@ this. | |||
21 | identify-component | 21 | identify-component |
22 | report-defect | 22 | report-defect |
23 | recipe-style-guide | 23 | recipe-style-guide |
24 | submit-change | 24 | submit-changes |
25 | 25 | ||
26 | .. include:: /boilerplate.rst | 26 | .. include:: /boilerplate.rst |
diff --git a/documentation/contributor-guide/submit-change.rst b/documentation/contributor-guide/submit-changes.rst index 6bee423bfb..3f6d2db96c 100644 --- a/documentation/contributor-guide/submit-change.rst +++ b/documentation/contributor-guide/submit-changes.rst | |||
@@ -1,6 +1,6 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK |
2 | 2 | ||
3 | Contributing a Change to a Component | 3 | Contributing Changes to a Component |
4 | ************************************ | 4 | ************************************ |
5 | 5 | ||
6 | Contributions to the Yocto Project and OpenEmbedded are very welcome. | 6 | Contributions to the Yocto Project and OpenEmbedded are very welcome. |
@@ -60,13 +60,13 @@ list you need to use depends on the location of the code you are | |||
60 | changing. Each component (e.g. layer) should have a ``README`` file that | 60 | changing. Each component (e.g. layer) should have a ``README`` file that |
61 | indicates where to send the changes and which process to follow. | 61 | indicates where to send the changes and which process to follow. |
62 | 62 | ||
63 | You can send the patch to the mailing list using whichever approach you | 63 | You can send the patches to the mailing list using whichever approach you |
64 | feel comfortable with to generate the patch. Once sent, the patch is | 64 | feel comfortable with to generate the patches. Once sent, the patches are |
65 | usually reviewed by the community at large. If somebody has concerns | 65 | usually reviewed by the community at large. If somebody has concerns |
66 | with the patch, they will usually voice their concern over the mailing | 66 | any of the the patches, they will usually voice their concern over the mailing |
67 | list. If a patch does not receive any negative reviews, the maintainer | 67 | list. If patches do not receive any negative reviews, the maintainer |
68 | of the affected layer typically takes the patch, tests it, and then | 68 | of the affected layer typically takes them, tests them, and then |
69 | based on successful testing, merges the patch. | 69 | based on successful testing, merges them. |
70 | 70 | ||
71 | The "poky" repository, which is the Yocto Project's reference build | 71 | The "poky" repository, which is the Yocto Project's reference build |
72 | environment, is a hybrid repository that contains several individual | 72 | environment, is a hybrid repository that contains several individual |
@@ -74,13 +74,13 @@ pieces (e.g. BitBake, Metadata, documentation, and so forth) built using | |||
74 | the combo-layer tool. The upstream location used for submitting changes | 74 | the combo-layer tool. The upstream location used for submitting changes |
75 | varies by component: | 75 | varies by component: |
76 | 76 | ||
77 | - *Core Metadata:* Send your patch to the | 77 | - *Core Metadata:* Send your patches to the |
78 | :oe_lists:`openembedded-core </g/openembedded-core>` | 78 | :oe_lists:`openembedded-core </g/openembedded-core>` |
79 | mailing list. For example, a change to anything under the ``meta`` or | 79 | mailing list. For example, a change to anything under the ``meta`` or |
80 | ``scripts`` directories should be sent to this mailing list. | 80 | ``scripts`` directories should be sent to this mailing list. |
81 | 81 | ||
82 | - *BitBake:* For changes to BitBake (i.e. anything under the | 82 | - *BitBake:* For changes to BitBake (i.e. anything under the |
83 | ``bitbake`` directory), send your patch to the | 83 | ``bitbake`` directory), send your patches to the |
84 | :oe_lists:`bitbake-devel </g/bitbake-devel>` | 84 | :oe_lists:`bitbake-devel </g/bitbake-devel>` |
85 | mailing list. | 85 | mailing list. |
86 | 86 | ||
@@ -101,13 +101,13 @@ repositories (i.e. ``yoctoproject.org``) and tools use the | |||
101 | 101 | ||
102 | For additional recipes that do not fit into the core Metadata, you | 102 | For additional recipes that do not fit into the core Metadata, you |
103 | should determine which layer the recipe should go into and submit the | 103 | should determine which layer the recipe should go into and submit the |
104 | change in the manner recommended by the documentation (e.g. the | 104 | changes in the manner recommended by the documentation (e.g. the |
105 | ``README`` file) supplied with the layer. If in doubt, please ask on the | 105 | ``README`` file) supplied with the layer. If in doubt, please ask on the |
106 | :yocto_lists:`yocto </g/yocto/>` general mailing list or on the | 106 | :yocto_lists:`yocto </g/yocto/>` general mailing list or on the |
107 | :oe_lists:`openembedded-devel </g/openembedded-devel>` mailing list. | 107 | :oe_lists:`openembedded-devel </g/openembedded-devel>` mailing list. |
108 | 108 | ||
109 | You can also push a change upstream and request a maintainer to pull the | 109 | You can also push changes upstream and request a maintainer to pull the |
110 | change into the component's upstream repository. You do this by pushing | 110 | changes into the component's upstream repository. You do this by pushing |
111 | to a contribution repository that is upstream. See the | 111 | to a contribution repository that is upstream. See the |
112 | ":ref:`overview-manual/development-environment:git workflows and the yocto project`" | 112 | ":ref:`overview-manual/development-environment:git workflows and the yocto project`" |
113 | section in the Yocto Project Overview and Concepts Manual for additional | 113 | section in the Yocto Project Overview and Concepts Manual for additional |
@@ -135,29 +135,43 @@ Other layers may have similar testing branches but there is no formal | |||
135 | requirement or standard for these so please check the documentation for the | 135 | requirement or standard for these so please check the documentation for the |
136 | layers you are contributing to. | 136 | layers you are contributing to. |
137 | 137 | ||
138 | The following sections provide procedures for submitting a change. | 138 | The following sections provide procedures for submitting changes. |
139 | 139 | ||
140 | Preparing Changes for Submission | 140 | Preparing Changes for Submission |
141 | ================================ | 141 | ================================ |
142 | 142 | ||
143 | #. *Make Your Changes Locally:* Make your changes in your local Git | 143 | The first thing to do is to create a new branch in your local Git repository |
144 | repository. You should make small, controlled, isolated changes. | 144 | for your changes, starting from the reference branch in the upstream |
145 | Keeping changes small and isolated aids review, makes | 145 | repository (often called ``master``):: |
146 | merging/rebasing easier and keeps the change history clean should | ||
147 | anyone need to refer to it in future. | ||
148 | 146 | ||
149 | #. *Stage Your Changes:* Stage your changes by using the ``git add`` | 147 | $ git checkout <ref-branch> |
150 | command on each file you changed. | 148 | $ git checkout -b my-changes |
151 | 149 | ||
152 | #. *Commit Your Changes:* Commit the change by using the ``git commit`` | 150 | If you have completely unrelated sets of changes to submit, you should even |
151 | create one branch for each set. | ||
152 | |||
153 | Then, in each branch, you should group your changes into small, controlled and | ||
154 | isolated ones. Keeping changes small and isolated aids review, makes | ||
155 | merging/rebasing easier and keeps the change history clean should anyone need | ||
156 | to refer to it in future. | ||
157 | |||
158 | To this purpose, you should create *one Git commit per change*, | ||
159 | corresponding to each of the patches you will eventually submit. | ||
160 | So, for each identified change: | ||
161 | |||
162 | #. *Stage Your Change:* Stage your change by using the ``git add`` | ||
163 | command on each file you modified. | ||
164 | |||
165 | #. *Commit Your Change:* Commit the change by using the ``git commit`` | ||
153 | command. Make sure your commit information follows standards by | 166 | command. Make sure your commit information follows standards by |
154 | following these accepted conventions: | 167 | following these accepted conventions: |
155 | 168 | ||
156 | - Be sure to include a "Signed-off-by:" line in the same style as | 169 | - Be sure to include a "Signed-off-by:" line in the same style as |
157 | required by the Linux kernel. This can be done by using the | 170 | required by the Linux kernel. This can be done by using the |
158 | ``git commit -s`` command. Adding this line signifies that you, | 171 | ``git commit -s`` command. Adding this line signifies that you, |
159 | the submitter, have agreed to the Developer's Certificate of | 172 | the submitter, have agreed to the `Developer's Certificate of Origin 1.1 |
160 | Origin 1.1 as follows: | 173 | <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__ |
174 | as follows: | ||
161 | 175 | ||
162 | .. code-block:: none | 176 | .. code-block:: none |
163 | 177 | ||
@@ -196,6 +210,14 @@ Preparing Changes for Submission | |||
196 | with the recipe name (if changing a recipe), or else with the | 210 | with the recipe name (if changing a recipe), or else with the |
197 | short form path to the file being changed. | 211 | short form path to the file being changed. |
198 | 212 | ||
213 | .. note:: | ||
214 | |||
215 | To find a suitable prefix for the commit summary, a good idea | ||
216 | is to look for prefixes used in previous commits touching the | ||
217 | same files or directories:: | ||
218 | |||
219 | git log --oneline <paths> | ||
220 | |||
199 | - For the body of the commit message, provide detailed information | 221 | - For the body of the commit message, provide detailed information |
200 | that describes what you changed, why you made the change, and the | 222 | that describes what you changed, why you made the change, and the |
201 | approach you used. It might also be helpful if you mention how you | 223 | approach you used. It might also be helpful if you mention how you |
@@ -220,50 +242,30 @@ Preparing Changes for Submission | |||
220 | 242 | ||
221 | detailed description of change | 243 | detailed description of change |
222 | 244 | ||
223 | Using Email to Submit a Patch | 245 | Using Email to Submit Patches |
224 | ============================= | 246 | ============================= |
225 | 247 | ||
226 | Depending on the components changed, you need to submit the email to a | 248 | Depending on the components changed, you need to submit the email to a |
227 | specific mailing list. For some guidance on which mailing list to use, | 249 | specific mailing list. For some guidance on which mailing list to use, |
228 | see the ":ref:`contributor-guide/submit-change:finding a suitable mailing list`" | 250 | see the ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" |
229 | section above. | 251 | section above. |
230 | 252 | ||
231 | Here is the general procedure on how to submit a patch through email | 253 | Here is the general procedure on how to create and submit patches through email: |
232 | without using the scripts once the steps in | ||
233 | ":ref:`contributor-guide/submit-change:preparing changes for submission`" | ||
234 | have been followed: | ||
235 | |||
236 | #. *Format the Commit:* Format the commit into an email message. To | ||
237 | format commits, use the ``git format-patch`` command. When you | ||
238 | provide the command, you must include a revision list or a number of | ||
239 | patches as part of the command. For example, either of these two | ||
240 | commands takes your most recent single commit and formats it as an | ||
241 | email message in the current directory:: | ||
242 | |||
243 | $ git format-patch -1 | ||
244 | |||
245 | or :: | ||
246 | 254 | ||
247 | $ git format-patch HEAD~ | 255 | #. *Generate Patches for your Branch:* The ``git format-patch`` command for |
256 | generate patch files for each of the commits in your branch. You need | ||
257 | to pass the reference branch your branch starts from:: | ||
248 | 258 | ||
249 | After the command is run, the current directory contains a numbered | 259 | $ git format-patch <ref-branch> |
250 | ``.patch`` file for the commit. | ||
251 | 260 | ||
252 | If you provide several commits as part of the command, the | 261 | After the command is run, the current directory contains numbered |
253 | ``git format-patch`` command produces a series of numbered files in | 262 | ``.patch`` files for the commits in your branch. |
254 | the current directory – one for each commit. If you have more than | ||
255 | one patch, you should also use the ``--cover`` option with the | ||
256 | command, which generates a cover letter as the first "patch" in the | ||
257 | series. You can then edit the cover letter to provide a description | ||
258 | for the series of patches. For information on the | ||
259 | ``git format-patch`` command, see ``GIT_FORMAT_PATCH(1)`` displayed | ||
260 | using the ``man git-format-patch`` command. | ||
261 | 263 | ||
262 | .. note:: | 264 | If you have more than one patch, you should also use the ``--cover`` |
263 | 265 | option with the command, which generates a cover letter as the first | |
264 | If you are or will be a frequent contributor to the Yocto Project | 266 | "patch" in the series. You can then edit the cover letter to provide |
265 | or to OpenEmbedded, you might consider requesting a contrib area | 267 | a description for the series of patches. Run ``man git-format-patch`` |
266 | and the necessary associated rights. | 268 | for details about this command. |
267 | 269 | ||
268 | #. *Send the patches via email:* Send the patches to the recipients and | 270 | #. *Send the patches via email:* Send the patches to the recipients and |
269 | relevant mailing lists by using the ``git send-email`` command. | 271 | relevant mailing lists by using the ``git send-email`` command. |
@@ -291,9 +293,11 @@ have been followed: | |||
291 | whitespace in the body of the message, which can occur when you use | 293 | whitespace in the body of the message, which can occur when you use |
292 | your own mail client. The command also has several options that let | 294 | your own mail client. The command also has several options that let |
293 | you specify recipients and perform further editing of the email | 295 | you specify recipients and perform further editing of the email |
294 | message. For information on how to use the ``git send-email`` | 296 | message. Here's a typical usage of this command:: |
295 | command, see ``GIT-SEND-EMAIL(1)`` displayed using the | 297 | |
296 | ``man git-send-email`` command. | 298 | git send-email --to <mailing-list-address> *.patch |
299 | |||
300 | Run ``man git-send-email`` for more details about this command. | ||
297 | 301 | ||
298 | The Yocto Project uses a `Patchwork instance <https://patchwork.yoctoproject.org/>`__ | 302 | The Yocto Project uses a `Patchwork instance <https://patchwork.yoctoproject.org/>`__ |
299 | to track the status of patches submitted to the various mailing lists and to | 303 | to track the status of patches submitted to the various mailing lists and to |
@@ -320,7 +324,7 @@ patch series with a link to the branch for review. | |||
320 | 324 | ||
321 | Follow this procedure to push a change to an upstream "contrib" Git | 325 | Follow this procedure to push a change to an upstream "contrib" Git |
322 | repository once the steps in | 326 | repository once the steps in |
323 | ":ref:`contributor-guide/submit-change:preparing changes for submission`" | 327 | ":ref:`contributor-guide/submit-changes:preparing changes for submission`" |
324 | have been followed: | 328 | have been followed: |
325 | 329 | ||
326 | .. note:: | 330 | .. note:: |
@@ -368,7 +372,7 @@ have been followed: | |||
368 | the file. | 372 | the file. |
369 | 373 | ||
370 | - *Find the Mailing List to Use:* See the | 374 | - *Find the Mailing List to Use:* See the |
371 | ":ref:`contributor-guide/submit-change:finding a suitable mailing list`" | 375 | ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" |
372 | section above. | 376 | section above. |
373 | 377 | ||
374 | #. *Make a Pull Request:* Notify the maintainer or the mailing list that | 378 | #. *Make a Pull Request:* Notify the maintainer or the mailing list that |
@@ -491,8 +495,8 @@ follows: | |||
491 | a newer version of the software which includes an upstream fix for the | 495 | a newer version of the software which includes an upstream fix for the |
492 | issue or when the issue has been fixed on the master branch in a way | 496 | issue or when the issue has been fixed on the master branch in a way |
493 | that introduces backwards incompatible changes. In this case follow the | 497 | that introduces backwards incompatible changes. In this case follow the |
494 | steps in ":ref:`contributor-guide/submit-change:preparing changes for submission`" and | 498 | steps in ":ref:`contributor-guide/submit-changes:preparing changes for submission`" and |
495 | ":ref:`contributor-guide/submit-change:using email to submit a patch`" | 499 | ":ref:`contributor-guide/submit-changes:using email to submit patches`" |
496 | but modify the subject header of your patch | 500 | but modify the subject header of your patch |
497 | email to include the name of the stable branch which you are | 501 | email to include the name of the stable branch which you are |
498 | targetting. This can be done using the ``--subject-prefix`` argument to | 502 | targetting. This can be done using the ``--subject-prefix`` argument to |
diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 890578cc05..fea2cb30a1 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst | |||
@@ -879,7 +879,7 @@ The build should work without issue. | |||
879 | As with all solved problems, if they originated upstream, you need to | 879 | As with all solved problems, if they originated upstream, you need to |
880 | submit the fix for the recipe in OE-Core and upstream so that the | 880 | submit the fix for the recipe in OE-Core and upstream so that the |
881 | problem is taken care of at its source. See the | 881 | problem is taken care of at its source. See the |
882 | ":doc:`../contributor-guide/submit-change`" section for more information. | 882 | ":doc:`../contributor-guide/submit-changes`" section for more information. |
883 | 883 | ||
884 | Debugging With the GNU Project Debugger (GDB) Remotely | 884 | Debugging With the GNU Project Debugger (GDB) Remotely |
885 | ====================================================== | 885 | ====================================================== |
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index 372959d9ed..88afa27ad5 100644 --- a/documentation/dev-manual/start.rst +++ b/documentation/dev-manual/start.rst | |||
@@ -246,13 +246,13 @@ particular working environment and set of practices. | |||
246 | - The Yocto Project community encourages you to send patches to the | 246 | - The Yocto Project community encourages you to send patches to the |
247 | project to fix bugs or add features. If you do submit patches, | 247 | project to fix bugs or add features. If you do submit patches, |
248 | follow the project commit guidelines for writing good commit | 248 | follow the project commit guidelines for writing good commit |
249 | messages. See the ":doc:`../contributor-guide/submit-change`" | 249 | messages. See the ":doc:`../contributor-guide/submit-changes`" |
250 | section in the Yocto Project and OpenEmbedded Contributor Guide. | 250 | section in the Yocto Project and OpenEmbedded Contributor Guide. |
251 | 251 | ||
252 | - Send changes to the core sooner than later as others are likely | 252 | - Send changes to the core sooner than later as others are likely |
253 | to run into the same issues. For some guidance on mailing lists | 253 | to run into the same issues. For some guidance on mailing lists |
254 | to use, see the lists in the | 254 | to use, see the lists in the |
255 | ":ref:`contributor-guide/submit-change:finding a suitable mailing list`" | 255 | ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" |
256 | section. For a description | 256 | section. For a description |
257 | of the available mailing lists, see the ":ref:`resources-mailinglist`" section in | 257 | of the available mailing lists, see the ":ref:`resources-mailinglist`" section in |
258 | the Yocto Project Reference Manual. | 258 | the Yocto Project Reference Manual. |
diff --git a/documentation/dev-manual/vulnerabilities.rst b/documentation/dev-manual/vulnerabilities.rst index 297789dae6..71111bb3e2 100644 --- a/documentation/dev-manual/vulnerabilities.rst +++ b/documentation/dev-manual/vulnerabilities.rst | |||
@@ -22,7 +22,7 @@ issues may be impacting Poky and OE-Core. It is up to the maintainers, users, | |||
22 | contributors and anyone interested in the issues to investigate and possibly fix them by | 22 | contributors and anyone interested in the issues to investigate and possibly fix them by |
23 | updating software components to newer versions or by applying patches to address them. | 23 | updating software components to newer versions or by applying patches to address them. |
24 | It is recommended to work with Poky and OE-Core upstream maintainers and submit | 24 | It is recommended to work with Poky and OE-Core upstream maintainers and submit |
25 | patches to fix them, see ":doc:`../contributor-guide/submit-change`" for details. | 25 | patches to fix them, see ":doc:`../contributor-guide/submit-changes`" for details. |
26 | 26 | ||
27 | Vulnerability check at build time | 27 | Vulnerability check at build time |
28 | ================================= | 28 | ================================= |
diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst index 55f34c18da..262d5cb203 100644 --- a/documentation/overview-manual/development-environment.rst +++ b/documentation/overview-manual/development-environment.rst | |||
@@ -264,7 +264,7 @@ push them into the "contrib" area and subsequently request that the | |||
264 | maintainer include them into an upstream branch. This process is called | 264 | maintainer include them into an upstream branch. This process is called |
265 | "submitting a patch" or "submitting a change." For information on | 265 | "submitting a patch" or "submitting a change." For information on |
266 | submitting patches and changes, see the | 266 | submitting patches and changes, see the |
267 | ":doc:`../contributor-guide/submit-change`" section in the Yocto Project | 267 | ":doc:`../contributor-guide/submit-changes`" section in the Yocto Project |
268 | and OpenEmbedded Contributor Guide. | 268 | and OpenEmbedded Contributor Guide. |
269 | 269 | ||
270 | In summary, there is a single point of entry for changes into the | 270 | In summary, there is a single point of entry for changes into the |
@@ -330,7 +330,7 @@ Book <https://book.git-scm.com>`__. | |||
330 | release to facilitate this workflow. You can find these scripts in | 330 | release to facilitate this workflow. You can find these scripts in |
331 | the ``scripts`` folder of the :term:`Source Directory`. For information | 331 | the ``scripts`` folder of the :term:`Source Directory`. For information |
332 | on how to use these scripts, see the | 332 | on how to use these scripts, see the |
333 | ":ref:`contributor-guide/submit-change:using scripts to push a change upstream and request a pull`" | 333 | ":ref:`contributor-guide/submit-changes:using scripts to push a change upstream and request a pull`" |
334 | section in the Yocto Project and OpenEmbedded Contributor Guide. | 334 | section in the Yocto Project and OpenEmbedded Contributor Guide. |
335 | 335 | ||
336 | - *Patch Workflow:* This workflow allows you to notify the maintainer | 336 | - *Patch Workflow:* This workflow allows you to notify the maintainer |
@@ -339,7 +339,7 @@ Book <https://book.git-scm.com>`__. | |||
339 | this type of change, you format the patch and then send the email | 339 | this type of change, you format the patch and then send the email |
340 | using the Git commands ``git format-patch`` and ``git send-email``. | 340 | using the Git commands ``git format-patch`` and ``git send-email``. |
341 | For information on how to use these scripts, see the | 341 | For information on how to use these scripts, see the |
342 | ":doc:`../contributor-guide/submit-change`" section in the Yocto Project | 342 | ":doc:`../contributor-guide/submit-changes`" section in the Yocto Project |
343 | and OpenEmbedded Contributor Guide. | 343 | and OpenEmbedded Contributor Guide. |
344 | 344 | ||
345 | Git | 345 | Git |