diff options
author | Michael Opdenacker <michael.opdenacker@bootlin.com> | 2023-08-02 16:01:13 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2023-08-30 15:54:59 +0100 |
commit | 8a11abf6a9dac76bf9739c44102a49984e3c2977 (patch) | |
tree | e9fad45beb65d1330dad49408de14cd164820bd4 /documentation | |
parent | ddf3b3ecd4b1680dc0dedfd4eaebcf3441b14ca7 (diff) | |
download | poky-8a11abf6a9dac76bf9739c44102a49984e3c2977.tar.gz |
manuals: create a dedicated "Contributor Guide" document
Starting from the original contents of dev-manual/changes.rst
and from text contributed by Richard Purdie.
(From yocto-docs rev: 55587d9dd009cbc92273376e0f7665b2d574d280)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r-- | documentation/bsp-guide/bsp.rst | 4 | ||||
-rw-r--r-- | documentation/contributor-guide/identify-component.rst | 29 | ||||
-rw-r--r-- | documentation/contributor-guide/index.rst | 25 | ||||
-rw-r--r-- | documentation/contributor-guide/submit-change.rst (renamed from documentation/dev-manual/changes.rst) | 102 | ||||
-rw-r--r-- | documentation/contributor-guide/submit-defect.rst | 67 | ||||
-rw-r--r-- | documentation/dev-manual/debugging.rst | 7 | ||||
-rw-r--r-- | documentation/dev-manual/index.rst | 3 | ||||
-rw-r--r-- | documentation/dev-manual/start.rst | 9 | ||||
-rw-r--r-- | documentation/dev-manual/vulnerabilities.rst | 2 | ||||
-rw-r--r-- | documentation/index.rst | 1 | ||||
-rw-r--r-- | documentation/overview-manual/development-environment.rst | 19 | ||||
-rw-r--r-- | documentation/ref-manual/resources.rst | 7 | ||||
-rw-r--r-- | documentation/ref-manual/system-requirements.rst | 4 |
13 files changed, 165 insertions, 114 deletions
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst index 4d64c65d91..52a07cfcb0 100644 --- a/documentation/bsp-guide/bsp.rst +++ b/documentation/bsp-guide/bsp.rst | |||
@@ -927,8 +927,8 @@ 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 | ":ref:`dev-manual/changes:submitting a change to the yocto project`" | 930 | :doc:`../contributor-guide/submit-change` section in the Yocto Project and |
931 | section in the Yocto Project Development Tasks Manual. | 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. |
934 | 934 | ||
diff --git a/documentation/contributor-guide/identify-component.rst b/documentation/contributor-guide/identify-component.rst new file mode 100644 index 0000000000..ba7c998888 --- /dev/null +++ b/documentation/contributor-guide/identify-component.rst | |||
@@ -0,0 +1,29 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
2 | |||
3 | Identify the component | ||
4 | ********************** | ||
5 | |||
6 | The Yocto Project and OpenEmbedded ecosystem is built of :term:`layers <Layer>` | ||
7 | so the first step is to identify the component where the issue likely lies. | ||
8 | For example, if you have a hardware issue, it is likely related to the BSP | ||
9 | you are using and the best place to seek advice would be from the BSP provider | ||
10 | or :term:`layer`. If the issue is a build/configuration one and a distro is in | ||
11 | use, they would likely be the first place to ask questions. If the issue is a | ||
12 | generic one and/or in the core classes or metadata, the core layer or BitBake | ||
13 | might be the appropriate component. | ||
14 | |||
15 | Each metadata layer being used should contain a ``README`` file and that should | ||
16 | explain where to report issues, where to send changes and how to contact the | ||
17 | maintainers. | ||
18 | |||
19 | If the issue is in the core metadata layer (OpenEmbedded-Core) or in BitBake, | ||
20 | issues can be reported in the :yocto_bugs:`Yocto Project Bugzilla <>`. The | ||
21 | :yocto_lists:`yocto </g/yocto>` mailing list is a general “catch-all” location | ||
22 | where questions can be sent if you can’t work out where something should go. | ||
23 | |||
24 | :term:`Poky` is a commonly used “combination” repository where multiple | ||
25 | components have been combined (``bitbake``, ``openembedded-core``, | ||
26 | ``meta-yocto`` and ``yocto-docs``). Patches should be submitted against | ||
27 | the appropriate individual component rather than :term:`Poky` itself as | ||
28 | detailed in the appropriate ``README`` file. | ||
29 | |||
diff --git a/documentation/contributor-guide/index.rst b/documentation/contributor-guide/index.rst new file mode 100644 index 0000000000..d723854843 --- /dev/null +++ b/documentation/contributor-guide/index.rst | |||
@@ -0,0 +1,25 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
2 | |||
3 | ================================================ | ||
4 | Yocto Project and OpenEmbedded Contributor Guide | ||
5 | ================================================ | ||
6 | |||
7 | The Yocto Project and OpenEmbedded are open-source, community-based projects so | ||
8 | contributions are very welcome, it is how the code evolves and everyone can | ||
9 | effect change. Contributions take different forms, if you have a fix for an | ||
10 | issue you’ve run into, a patch is the most appropriate way to contribute it. | ||
11 | If you run into an issue but don’t have a solution, opening a defect in | ||
12 | :yocto_bugs:`Bugzilla <>` or asking questions on the mailing lists might be | ||
13 | more appropriate. This guide intends to point you in the right direction to | ||
14 | this. | ||
15 | |||
16 | |||
17 | .. toctree:: | ||
18 | :caption: Table of Contents | ||
19 | :numbered: | ||
20 | |||
21 | identify-component | ||
22 | submit-defect | ||
23 | submit-change | ||
24 | |||
25 | .. include:: /boilerplate.rst | ||
diff --git a/documentation/dev-manual/changes.rst b/documentation/contributor-guide/submit-change.rst index 9db6ce010c..ba56e5986d 100644 --- a/documentation/dev-manual/changes.rst +++ b/documentation/contributor-guide/submit-change.rst | |||
@@ -1,79 +1,16 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK |
2 | 2 | ||
3 | Making Changes to the Yocto Project | 3 | Contributing a Change to a Component |
4 | *********************************** | 4 | ************************************ |
5 | |||
6 | Because the Yocto Project is an open-source, community-based project, | ||
7 | you can effect changes to the project. This section presents procedures | ||
8 | that show you how to submit a defect against the project and how to | ||
9 | submit a change. | ||
10 | |||
11 | Submitting a Defect Against the Yocto Project | ||
12 | ============================================= | ||
13 | |||
14 | Use the Yocto Project implementation of | ||
15 | `Bugzilla <https://www.bugzilla.org/about/>`__ to submit a defect (bug) | ||
16 | against the Yocto Project. For additional information on this | ||
17 | implementation of Bugzilla see the ":ref:`Yocto Project | ||
18 | Bugzilla <resources-bugtracker>`" section in the | ||
19 | Yocto Project Reference Manual. For more detail on any of the following | ||
20 | steps, see the Yocto Project | ||
21 | :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`. | ||
22 | |||
23 | Use the following general steps to submit a bug: | ||
24 | |||
25 | #. Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`. | ||
26 | |||
27 | #. Click "File a Bug" to enter a new bug. | ||
28 | |||
29 | #. Choose the appropriate "Classification", "Product", and "Component" | ||
30 | for which the bug was found. Bugs for the Yocto Project fall into | ||
31 | one of several classifications, which in turn break down into | ||
32 | several products and components. For example, for a bug against the | ||
33 | ``meta-intel`` layer, you would choose "Build System, Metadata & | ||
34 | Runtime", "BSPs", and "bsps-meta-intel", respectively. | ||
35 | |||
36 | #. Choose the "Version" of the Yocto Project for which you found the | ||
37 | bug (e.g. &DISTRO;). | ||
38 | |||
39 | #. Determine and select the "Severity" of the bug. The severity | ||
40 | indicates how the bug impacted your work. | ||
41 | |||
42 | #. Choose the "Hardware" that the bug impacts. | ||
43 | |||
44 | #. Choose the "Architecture" that the bug impacts. | ||
45 | |||
46 | #. Choose a "Documentation change" item for the bug. Fixing a bug might | ||
47 | or might not affect the Yocto Project documentation. If you are | ||
48 | unsure of the impact to the documentation, select "Don't Know". | ||
49 | |||
50 | #. Provide a brief "Summary" of the bug. Try to limit your summary to | ||
51 | just a line or two and be sure to capture the essence of the bug. | ||
52 | |||
53 | #. Provide a detailed "Description" of the bug. You should provide as | ||
54 | much detail as you can about the context, behavior, output, and so | ||
55 | forth that surrounds the bug. You can even attach supporting files | ||
56 | for output from logs by using the "Add an attachment" button. | ||
57 | |||
58 | #. Click the "Submit Bug" button submit the bug. A new Bugzilla number | ||
59 | is assigned to the bug and the defect is logged in the bug tracking | ||
60 | system. | ||
61 | |||
62 | Once you file a bug, the bug is processed by the Yocto Project Bug | ||
63 | Triage Team and further details concerning the bug are assigned (e.g. | ||
64 | priority and owner). You are the "Submitter" of the bug and any further | ||
65 | categorization, progress, or comments on the bug result in Bugzilla | ||
66 | sending you an automated email concerning the particular change or | ||
67 | progress to the bug. | ||
68 | |||
69 | Submitting a Change to the Yocto Project | ||
70 | ======================================== | ||
71 | 5 | ||
72 | Contributions to the Yocto Project and OpenEmbedded are very welcome. | 6 | Contributions to the Yocto Project and OpenEmbedded are very welcome. |
73 | Because the system is extremely configurable and flexible, we recognize | 7 | Because the system is extremely configurable and flexible, we recognize |
74 | that developers will want to extend, configure or optimize it for their | 8 | that developers will want to extend, configure or optimize it for their |
75 | specific uses. | 9 | specific uses. |
76 | 10 | ||
11 | Finding a Suitable Mailing List | ||
12 | =============================== | ||
13 | |||
77 | The Yocto Project uses a mailing list and a patch-based workflow that is | 14 | The Yocto Project uses a mailing list and a patch-based workflow that is |
78 | similar to the Linux kernel but contains important differences. In | 15 | similar to the Linux kernel but contains important differences. In |
79 | general, there is a mailing list through which you can submit patches. You | 16 | general, there is a mailing list through which you can submit patches. You |
@@ -160,7 +97,7 @@ layers you are contributing to. | |||
160 | The following sections provide procedures for submitting a change. | 97 | The following sections provide procedures for submitting a change. |
161 | 98 | ||
162 | Preparing Changes for Submission | 99 | Preparing Changes for Submission |
163 | -------------------------------- | 100 | ================================ |
164 | 101 | ||
165 | #. *Make Your Changes Locally:* Make your changes in your local Git | 102 | #. *Make Your Changes Locally:* Make your changes in your local Git |
166 | repository. You should make small, controlled, isolated changes. | 103 | repository. You should make small, controlled, isolated changes. |
@@ -243,19 +180,19 @@ Preparing Changes for Submission | |||
243 | detailed description of change | 180 | detailed description of change |
244 | 181 | ||
245 | Using Email to Submit a Patch | 182 | Using Email to Submit a Patch |
246 | ----------------------------- | 183 | ============================= |
247 | 184 | ||
248 | Depending on the components changed, you need to submit the email to a | 185 | Depending on the components changed, you need to submit the email to a |
249 | specific mailing list. For some guidance on which mailing list to use, | 186 | specific mailing list. For some guidance on which mailing list to use, |
250 | see the | 187 | see the ":ref:`contributor-guide/submit-change:finding a suitable mailing list`" |
251 | :ref:`list <dev-manual/changes:submitting a change to the yocto project>` | 188 | section above. For a description of all the available |
252 | at the beginning of this section. For a description of all the available | ||
253 | mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the | 189 | mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the |
254 | Yocto Project Reference Manual. | 190 | Yocto Project Reference Manual. |
255 | 191 | ||
256 | Here is the general procedure on how to submit a patch through email | 192 | Here is the general procedure on how to submit a patch through email |
257 | without using the scripts once the steps in | 193 | without using the scripts once the steps in |
258 | :ref:`dev-manual/changes:preparing changes for submission` have been followed: | 194 | ":ref:`contributor-guide/submit-change:preparing changes for submission`" |
195 | have been followed: | ||
259 | 196 | ||
260 | #. *Format the Commit:* Format the commit into an email message. To | 197 | #. *Format the Commit:* Format the commit into an email message. To |
261 | format commits, use the ``git format-patch`` command. When you | 198 | format commits, use the ``git format-patch`` command. When you |
@@ -333,7 +270,7 @@ reduce the burden of patch review on maintainers. | |||
333 | has been idle for a while with no feedback. | 270 | has been idle for a while with no feedback. |
334 | 271 | ||
335 | Using Scripts to Push a Change Upstream and Request a Pull | 272 | Using Scripts to Push a Change Upstream and Request a Pull |
336 | ---------------------------------------------------------- | 273 | ========================================================== |
337 | 274 | ||
338 | For larger patch series it is preferable to send a pull request which not | 275 | For larger patch series it is preferable to send a pull request which not |
339 | only includes the patch but also a pointer to a branch that can be pulled | 276 | only includes the patch but also a pointer to a branch that can be pulled |
@@ -343,8 +280,9 @@ and ``send-pull-request`` scripts from openembedded-core to create and send a | |||
343 | patch series with a link to the branch for review. | 280 | patch series with a link to the branch for review. |
344 | 281 | ||
345 | Follow this procedure to push a change to an upstream "contrib" Git | 282 | Follow this procedure to push a change to an upstream "contrib" Git |
346 | repository once the steps in :ref:`dev-manual/changes:preparing changes for submission` have | 283 | repository once the steps in |
347 | been followed: | 284 | ":ref:`contributor-guide/submit-change:preparing changes for submission`" |
285 | have been followed: | ||
348 | 286 | ||
349 | .. note:: | 287 | .. note:: |
350 | 288 | ||
@@ -442,7 +380,7 @@ been followed: | |||
442 | $ poky/scripts/send-pull-request -h | 380 | $ poky/scripts/send-pull-request -h |
443 | 381 | ||
444 | Responding to Patch Review | 382 | Responding to Patch Review |
445 | -------------------------- | 383 | ========================== |
446 | 384 | ||
447 | You may get feedback on your submitted patches from other community members | 385 | You may get feedback on your submitted patches from other community members |
448 | or from the automated patchtest service. If issues are identified in your | 386 | or from the automated patchtest service. If issues are identified in your |
@@ -464,7 +402,7 @@ please don't just edit the patch file written out by ``git format-patch`` and | |||
464 | resend it. | 402 | resend it. |
465 | 403 | ||
466 | Submitting Changes to Stable Release Branches | 404 | Submitting Changes to Stable Release Branches |
467 | --------------------------------------------- | 405 | ============================================= |
468 | 406 | ||
469 | The process for proposing changes to a Yocto Project stable branch differs | 407 | The process for proposing changes to a Yocto Project stable branch differs |
470 | from the steps described above. Changes to a stable branch must address | 408 | from the steps described above. Changes to a stable branch must address |
@@ -515,11 +453,11 @@ follows: | |||
515 | a newer version of the software which includes an upstream fix for the | 453 | a newer version of the software which includes an upstream fix for the |
516 | issue or when the issue has been fixed on the master branch in a way | 454 | issue or when the issue has been fixed on the master branch in a way |
517 | that introduces backwards incompatible changes. In this case follow the | 455 | that introduces backwards incompatible changes. In this case follow the |
518 | steps in :ref:`dev-manual/changes:preparing changes for submission` and | 456 | steps in ":ref:`contributor-guide/submit-change:preparing changes for submission`" and |
519 | :ref:`dev-manual/changes:using email to submit a patch` but modify the subject header of your patch | 457 | ":ref:`contributor-guide/submit-change:using email to submit a patch`" |
458 | but modify the subject header of your patch | ||
520 | email to include the name of the stable branch which you are | 459 | email to include the name of the stable branch which you are |
521 | targetting. This can be done using the ``--subject-prefix`` argument to | 460 | targetting. This can be done using the ``--subject-prefix`` argument to |
522 | ``git format-patch``, for example to submit a patch to the dunfell | 461 | ``git format-patch``, for example to submit a patch to the dunfell |
523 | branch use | 462 | branch use |
524 | ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``. | 463 | ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``. |
525 | |||
diff --git a/documentation/contributor-guide/submit-defect.rst b/documentation/contributor-guide/submit-defect.rst new file mode 100644 index 0000000000..527ffb2dc0 --- /dev/null +++ b/documentation/contributor-guide/submit-defect.rst | |||
@@ -0,0 +1,67 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
2 | |||
3 | Submitting a Defect Against the Yocto Project and OpenEmbedded | ||
4 | ************************************************************** | ||
5 | |||
6 | You can use the Yocto Project instance of | ||
7 | `Bugzilla <https://www.bugzilla.org/about/>`__ to submit a defect (bug) | ||
8 | against BitBake, OpenEmbedded-Core, against any other Yocto Project component | ||
9 | or for tool issues. For additional information on this implementation of | ||
10 | Bugzilla see the ":ref:`Yocto Project Bugzilla <resources-bugtracker>`" section | ||
11 | in the Yocto Project Reference Manual. For more detail on any of the following | ||
12 | steps, see the Yocto Project | ||
13 | :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`. | ||
14 | |||
15 | Use the following general steps to submit a bug: | ||
16 | |||
17 | #. Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`. | ||
18 | |||
19 | #. Click "File a Bug" to enter a new bug. | ||
20 | |||
21 | #. Choose the appropriate "Classification", "Product", and "Component" | ||
22 | for which the bug was found. Bugs for the Yocto Project fall into | ||
23 | one of several classifications, which in turn break down into | ||
24 | several products and components. For example, for a bug against the | ||
25 | ``meta-intel`` layer, you would choose "Build System, Metadata & | ||
26 | Runtime", "BSPs", and "bsps-meta-intel", respectively. | ||
27 | |||
28 | #. Choose the "Version" of the Yocto Project for which you found the | ||
29 | bug (e.g. &DISTRO;). | ||
30 | |||
31 | #. Determine and select the "Severity" of the bug. The severity | ||
32 | indicates how the bug impacted your work. | ||
33 | |||
34 | #. Choose the "Hardware" that the bug impacts. | ||
35 | |||
36 | #. Choose the "Architecture" that the bug impacts. | ||
37 | |||
38 | #. Choose a "Documentation change" item for the bug. Fixing a bug might | ||
39 | or might not affect the Yocto Project documentation. If you are | ||
40 | unsure of the impact to the documentation, select "Don't Know". | ||
41 | |||
42 | #. Provide a brief "Summary" of the bug. Try to limit your summary to | ||
43 | just a line or two and be sure to capture the essence of the bug. | ||
44 | |||
45 | #. Provide a detailed "Description" of the bug. You should provide as | ||
46 | much detail as you can about the context, behavior, output, and so | ||
47 | forth that surrounds the bug. You can even attach supporting files | ||
48 | for output from logs by using the "Add an attachment" button. | ||
49 | |||
50 | #. Click the "Submit Bug" button submit the bug. A new Bugzilla number | ||
51 | is assigned to the bug and the defect is logged in the bug tracking | ||
52 | system. | ||
53 | |||
54 | Once you file a bug, the bug is processed by the Yocto Project Bug | ||
55 | Triage Team and further details concerning the bug are assigned (e.g. | ||
56 | priority and owner). You are the "Submitter" of the bug and any further | ||
57 | categorization, progress, or comments on the bug result in Bugzilla | ||
58 | sending you an automated email concerning the particular change or | ||
59 | progress to the bug. | ||
60 | |||
61 | There are no guarantees about if or when a bug might be worked on since an | ||
62 | open-source project has no dedicated engineering resources. However, the | ||
63 | project does have a good track record of resolving common issues over the | ||
64 | medium and long term. We do encourage people to file bugs so issues are | ||
65 | at least known about. It helps other users when they find somebody having | ||
66 | the same issue as they do, and an issue that is unknown is much less likely | ||
67 | to ever be fixed! | ||
diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 3c5609cef5..3a8d5080ce 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst | |||
@@ -879,8 +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 | ":ref:`dev-manual/changes:submitting a change to the yocto project`" | 882 | ":doc:`../contributor-guide/submit-change`" section for more information. |
883 | section for more information. | ||
884 | 883 | ||
885 | Debugging With the GNU Project Debugger (GDB) Remotely | 884 | Debugging With the GNU Project Debugger (GDB) Remotely |
886 | ====================================================== | 885 | ====================================================== |
@@ -1236,9 +1235,7 @@ Here are some other tips that you might find useful: | |||
1236 | :yocto_bugs:`Bugzilla <>`. For information on | 1235 | :yocto_bugs:`Bugzilla <>`. For information on |
1237 | how to submit a bug against the Yocto Project, see the Yocto Project | 1236 | how to submit a bug against the Yocto Project, see the Yocto Project |
1238 | Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>` | 1237 | Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>` |
1239 | and the | 1238 | and the ":doc:`../contributor-guide/submit-defect`" section. |
1240 | ":ref:`dev-manual/changes:submitting a defect against the yocto project`" | ||
1241 | section. | ||
1242 | 1239 | ||
1243 | .. note:: | 1240 | .. note:: |
1244 | 1241 | ||
diff --git a/documentation/dev-manual/index.rst b/documentation/dev-manual/index.rst index b0bb5576ad..3106b90a45 100644 --- a/documentation/dev-manual/index.rst +++ b/documentation/dev-manual/index.rst | |||
@@ -4,8 +4,6 @@ | |||
4 | Yocto Project Development Tasks Manual | 4 | Yocto Project Development Tasks Manual |
5 | ====================================== | 5 | ====================================== |
6 | 6 | ||
7 | | | ||
8 | |||
9 | .. toctree:: | 7 | .. toctree:: |
10 | :caption: Table of Contents | 8 | :caption: Table of Contents |
11 | :numbered: | 9 | :numbered: |
@@ -43,7 +41,6 @@ Yocto Project Development Tasks Manual | |||
43 | build-quality | 41 | build-quality |
44 | runtime-testing | 42 | runtime-testing |
45 | debugging | 43 | debugging |
46 | changes | ||
47 | licenses | 44 | licenses |
48 | vulnerabilities | 45 | vulnerabilities |
49 | sbom | 46 | sbom |
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index 4881481044..372959d9ed 100644 --- a/documentation/dev-manual/start.rst +++ b/documentation/dev-manual/start.rst | |||
@@ -246,14 +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 | 249 | messages. See the ":doc:`../contributor-guide/submit-change`" |
250 | ":ref:`dev-manual/changes:submitting a change to the yocto project`" | 250 | section in the Yocto Project and OpenEmbedded Contributor Guide. |
251 | section. | ||
252 | 251 | ||
253 | - 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 |
254 | 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 |
255 | to use, see the list in the | 254 | to use, see the lists in the |
256 | ":ref:`dev-manual/changes:submitting a change to the yocto project`" | 255 | ":ref:`contributor-guide/submit-change:finding a suitable mailing list`" |
257 | section. For a description | 256 | section. For a description |
258 | 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 |
259 | 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 6d87d02ecb..297789dae6 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 ":ref:`dev-manual/changes:submitting a change to the yocto project`" for details. | 25 | patches to fix them, see ":doc:`../contributor-guide/submit-change`" for details. |
26 | 26 | ||
27 | Vulnerability check at build time | 27 | Vulnerability check at build time |
28 | ================================= | 28 | ================================= |
diff --git a/documentation/index.rst b/documentation/index.rst index 6335c707e0..4d0231503d 100644 --- a/documentation/index.rst +++ b/documentation/index.rst | |||
@@ -34,6 +34,7 @@ Welcome to the Yocto Project Documentation | |||
34 | Application Development and the Extensible SDK (eSDK) <sdk-manual/index> | 34 | Application Development and the Extensible SDK (eSDK) <sdk-manual/index> |
35 | Toaster Manual <toaster-manual/index> | 35 | Toaster Manual <toaster-manual/index> |
36 | Test Environment Manual <test-manual/index> | 36 | Test Environment Manual <test-manual/index> |
37 | Contributor Guide <contributor-guide/index> | ||
37 | bitbake | 38 | bitbake |
38 | 39 | ||
39 | .. toctree:: | 40 | .. toctree:: |
diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst index 6139e7a412..55f34c18da 100644 --- a/documentation/overview-manual/development-environment.rst +++ b/documentation/overview-manual/development-environment.rst | |||
@@ -232,8 +232,8 @@ and so forth. | |||
232 | 232 | ||
233 | For information on finding out who is responsible for (maintains) a | 233 | For information on finding out who is responsible for (maintains) a |
234 | particular area of code in the Yocto Project, see the | 234 | particular area of code in the Yocto Project, see the |
235 | ":ref:`dev-manual/changes:submitting a change to the yocto project`" | 235 | ":doc:`../contributor-guide/identify-component`" |
236 | section of the Yocto Project Development Tasks Manual. | 236 | section of the Yocto Project and OpenEmbedded Contributor Guide. |
237 | 237 | ||
238 | The Yocto Project ``poky`` Git repository also has an upstream | 238 | The Yocto Project ``poky`` Git repository also has an upstream |
239 | contribution Git repository named ``poky-contrib``. You can see all the | 239 | contribution Git repository named ``poky-contrib``. You can see all the |
@@ -264,8 +264,8 @@ 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 | ":ref:`dev-manual/changes:submitting a change to the yocto project`" | 267 | ":doc:`../contributor-guide/submit-change`" section in the Yocto Project |
268 | section in the Yocto Project Development Tasks Manual. | 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 |
271 | development branch of the Git repository, which is controlled by the | 271 | development branch of the Git repository, which is controlled by the |
@@ -328,11 +328,10 @@ Book <https://book.git-scm.com>`__. | |||
328 | software on which to develop. The Yocto Project has two scripts named | 328 | software on which to develop. The Yocto Project has two scripts named |
329 | ``create-pull-request`` and ``send-pull-request`` that ship with the | 329 | ``create-pull-request`` and ``send-pull-request`` that ship with the |
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 | 331 | the ``scripts`` folder of the :term:`Source Directory`. For information |
332 | :term:`Source Directory`. For information | ||
333 | on how to use these scripts, see the | 332 | on how to use these scripts, see the |
334 | ":ref:`dev-manual/changes:using scripts to push a change upstream and request a pull`" | 333 | ":ref:`contributor-guide/submit-change:using scripts to push a change upstream and request a pull`" |
335 | section in the Yocto Project Development Tasks Manual. | 334 | section in the Yocto Project and OpenEmbedded Contributor Guide. |
336 | 335 | ||
337 | - *Patch Workflow:* This workflow allows you to notify the maintainer | 336 | - *Patch Workflow:* This workflow allows you to notify the maintainer |
338 | through an email that you have a change (or patch) you would like | 337 | through an email that you have a change (or patch) you would like |
@@ -340,8 +339,8 @@ Book <https://book.git-scm.com>`__. | |||
340 | 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 |
341 | using the Git commands ``git format-patch`` and ``git send-email``. | 340 | using the Git commands ``git format-patch`` and ``git send-email``. |
342 | For information on how to use these scripts, see the | 341 | For information on how to use these scripts, see the |
343 | ":ref:`dev-manual/changes:submitting a change to the yocto project`" | 342 | ":doc:`../contributor-guide/submit-change`" section in the Yocto Project |
344 | section in the Yocto Project Development Tasks Manual. | 343 | and OpenEmbedded Contributor Guide. |
345 | 344 | ||
346 | Git | 345 | Git |
347 | === | 346 | === |
diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst index d2344e39a0..324d1fad10 100644 --- a/documentation/ref-manual/resources.rst +++ b/documentation/ref-manual/resources.rst | |||
@@ -23,8 +23,7 @@ The Yocto Project gladly accepts contributions. You can submit changes | |||
23 | to the project either by creating and sending pull requests, or by | 23 | to the project either by creating and sending pull requests, or by |
24 | submitting patches through email. For information on how to do both as | 24 | submitting patches through email. For information on how to do both as |
25 | well as information on how to identify the maintainer for each area of | 25 | well as information on how to identify the maintainer for each area of |
26 | code, see the ":ref:`dev-manual/changes:submitting a change to the yocto project`" section in the | 26 | code, see the :doc:`../contributor-guide/index`. |
27 | Yocto Project Development Tasks Manual. | ||
28 | 27 | ||
29 | .. _resources-bugtracker: | 28 | .. _resources-bugtracker: |
30 | 29 | ||
@@ -46,8 +45,8 @@ your expectations). | |||
46 | For a general procedure and guidelines on how to use Bugzilla to submit a bug | 45 | For a general procedure and guidelines on how to use Bugzilla to submit a bug |
47 | against the Yocto Project, see the following: | 46 | against the Yocto Project, see the following: |
48 | 47 | ||
49 | - The ":ref:`dev-manual/changes:submitting a defect against the yocto project`" | 48 | - The ":doc:`../contributor-guide/submit-defect`" |
50 | section in the Yocto Project Development Tasks Manual. | 49 | section in the Yocto Project and OpenEmbedded Contributor Guide. |
51 | 50 | ||
52 | - The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>` | 51 | - The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>` |
53 | 52 | ||
diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index d6e8b4583c..3c2f979a6d 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst | |||
@@ -114,8 +114,8 @@ Currently, the Yocto Project is supported on the following distributions: | |||
114 | interested in hearing about your experience. For information on | 114 | interested in hearing about your experience. For information on |
115 | how to submit a bug, see the Yocto Project | 115 | how to submit a bug, see the Yocto Project |
116 | :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>` | 116 | :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>` |
117 | and the ":ref:`dev-manual/changes:submitting a defect against the yocto project`" | 117 | and the ":doc:`../contributor-guide/submit-defect`" |
118 | section in the Yocto Project Development Tasks Manual. | 118 | section in the Yocto Project and OpenEmbedded Contributor Guide. |
119 | 119 | ||
120 | 120 | ||
121 | Required Packages for the Build Host | 121 | Required Packages for the Build Host |