diff options
Diffstat (limited to 'documentation/dev-manual/changes.rst')
-rw-r--r-- | documentation/dev-manual/changes.rst | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/documentation/dev-manual/changes.rst b/documentation/dev-manual/changes.rst index 8ccbf0d7ee..9cb25f3549 100644 --- a/documentation/dev-manual/changes.rst +++ b/documentation/dev-manual/changes.rst | |||
@@ -22,40 +22,40 @@ steps, see the Yocto Project | |||
22 | 22 | ||
23 | Use the following general steps to submit a bug: | 23 | Use the following general steps to submit a bug: |
24 | 24 | ||
25 | 1. Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`. | 25 | #. Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`. |
26 | 26 | ||
27 | 2. Click "File a Bug" to enter a new bug. | 27 | #. Click "File a Bug" to enter a new bug. |
28 | 28 | ||
29 | 3. Choose the appropriate "Classification", "Product", and "Component" | 29 | #. Choose the appropriate "Classification", "Product", and "Component" |
30 | for which the bug was found. Bugs for the Yocto Project fall into | 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 | 31 | one of several classifications, which in turn break down into |
32 | several products and components. For example, for a bug against the | 32 | several products and components. For example, for a bug against the |
33 | ``meta-intel`` layer, you would choose "Build System, Metadata & | 33 | ``meta-intel`` layer, you would choose "Build System, Metadata & |
34 | Runtime", "BSPs", and "bsps-meta-intel", respectively. | 34 | Runtime", "BSPs", and "bsps-meta-intel", respectively. |
35 | 35 | ||
36 | 4. Choose the "Version" of the Yocto Project for which you found the | 36 | #. Choose the "Version" of the Yocto Project for which you found the |
37 | bug (e.g. &DISTRO;). | 37 | bug (e.g. &DISTRO;). |
38 | 38 | ||
39 | 5. Determine and select the "Severity" of the bug. The severity | 39 | #. Determine and select the "Severity" of the bug. The severity |
40 | indicates how the bug impacted your work. | 40 | indicates how the bug impacted your work. |
41 | 41 | ||
42 | 6. Choose the "Hardware" that the bug impacts. | 42 | #. Choose the "Hardware" that the bug impacts. |
43 | 43 | ||
44 | 7. Choose the "Architecture" that the bug impacts. | 44 | #. Choose the "Architecture" that the bug impacts. |
45 | 45 | ||
46 | 8. Choose a "Documentation change" item for the bug. Fixing a bug might | 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 | 47 | or might not affect the Yocto Project documentation. If you are |
48 | unsure of the impact to the documentation, select "Don't Know". | 48 | unsure of the impact to the documentation, select "Don't Know". |
49 | 49 | ||
50 | 9. Provide a brief "Summary" of the bug. Try to limit your summary to | 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. | 51 | just a line or two and be sure to capture the essence of the bug. |
52 | 52 | ||
53 | 10. Provide a detailed "Description" of the bug. You should provide as | 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 | 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 | 55 | forth that surrounds the bug. You can even attach supporting files |
56 | for output from logs by using the "Add an attachment" button. | 56 | for output from logs by using the "Add an attachment" button. |
57 | 57 | ||
58 | 11. Click the "Submit Bug" button submit the bug. A new Bugzilla number | 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 | 59 | is assigned to the bug and the defect is logged in the bug tracking |
60 | system. | 60 | system. |
61 | 61 | ||
@@ -162,16 +162,16 @@ The following sections provide procedures for submitting a change. | |||
162 | Preparing Changes for Submission | 162 | Preparing Changes for Submission |
163 | -------------------------------- | 163 | -------------------------------- |
164 | 164 | ||
165 | 1. *Make Your Changes Locally:* Make your changes in your local Git | 165 | #. *Make Your Changes Locally:* Make your changes in your local Git |
166 | repository. You should make small, controlled, isolated changes. | 166 | repository. You should make small, controlled, isolated changes. |
167 | Keeping changes small and isolated aids review, makes | 167 | Keeping changes small and isolated aids review, makes |
168 | merging/rebasing easier and keeps the change history clean should | 168 | merging/rebasing easier and keeps the change history clean should |
169 | anyone need to refer to it in future. | 169 | anyone need to refer to it in future. |
170 | 170 | ||
171 | 2. *Stage Your Changes:* Stage your changes by using the ``git add`` | 171 | #. *Stage Your Changes:* Stage your changes by using the ``git add`` |
172 | command on each file you changed. | 172 | command on each file you changed. |
173 | 173 | ||
174 | 3. *Commit Your Changes:* Commit the change by using the ``git commit`` | 174 | #. *Commit Your Changes:* Commit the change by using the ``git commit`` |
175 | command. Make sure your commit information follows standards by | 175 | command. Make sure your commit information follows standards by |
176 | following these accepted conventions: | 176 | following these accepted conventions: |
177 | 177 | ||
@@ -257,7 +257,7 @@ Here is the general procedure on how to submit a patch through email | |||
257 | without using the scripts once the steps in | 257 | without using the scripts once the steps in |
258 | :ref:`dev-manual/changes:preparing changes for submission` have been followed: | 258 | :ref:`dev-manual/changes:preparing changes for submission` have been followed: |
259 | 259 | ||
260 | 1. *Format the Commit:* Format the commit into an email message. To | 260 | #. *Format the Commit:* Format the commit into an email message. To |
261 | format commits, use the ``git format-patch`` command. When you | 261 | format commits, use the ``git format-patch`` command. When you |
262 | provide the command, you must include a revision list or a number of | 262 | provide the command, you must include a revision list or a number of |
263 | patches as part of the command. For example, either of these two | 263 | patches as part of the command. For example, either of these two |
@@ -289,7 +289,7 @@ without using the scripts once the steps in | |||
289 | or to OpenEmbedded, you might consider requesting a contrib area | 289 | or to OpenEmbedded, you might consider requesting a contrib area |
290 | and the necessary associated rights. | 290 | and the necessary associated rights. |
291 | 291 | ||
292 | 2. *Send the patches via email:* Send the patches to the recipients and | 292 | #. *Send the patches via email:* Send the patches to the recipients and |
293 | relevant mailing lists by using the ``git send-email`` command. | 293 | relevant mailing lists by using the ``git send-email`` command. |
294 | 294 | ||
295 | .. note:: | 295 | .. note:: |
@@ -352,7 +352,7 @@ been followed: | |||
352 | in the | 352 | in the |
353 | `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__. | 353 | `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__. |
354 | 354 | ||
355 | 1. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for | 355 | #. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for |
356 | permissions to push to an upstream contrib repository, push the | 356 | permissions to push to an upstream contrib repository, push the |
357 | change to that repository:: | 357 | change to that repository:: |
358 | 358 | ||
@@ -367,7 +367,7 @@ been followed: | |||
367 | 367 | ||
368 | $ git push meta-intel-contrib your_name/README | 368 | $ git push meta-intel-contrib your_name/README |
369 | 369 | ||
370 | 2. *Determine Who to Notify:* Determine the maintainer or the mailing | 370 | #. *Determine Who to Notify:* Determine the maintainer or the mailing |
371 | list that you need to notify for the change. | 371 | list that you need to notify for the change. |
372 | 372 | ||
373 | Before submitting any change, you need to be sure who the maintainer | 373 | Before submitting any change, you need to be sure who the maintainer |
@@ -395,7 +395,7 @@ been followed: | |||
395 | lists <resources-mailinglist>`" section in | 395 | lists <resources-mailinglist>`" section in |
396 | the Yocto Project Reference Manual. | 396 | the Yocto Project Reference Manual. |
397 | 397 | ||
398 | 3. *Make a Pull Request:* Notify the maintainer or the mailing list that | 398 | #. *Make a Pull Request:* Notify the maintainer or the mailing list that |
399 | you have pushed a change by making a pull request. | 399 | you have pushed a change by making a pull request. |
400 | 400 | ||
401 | The Yocto Project provides two scripts that conveniently let you | 401 | The Yocto Project provides two scripts that conveniently let you |
@@ -486,30 +486,30 @@ branch can be obtained from the | |||
486 | With this in mind, the steps to submit a change for a stable branch are as | 486 | With this in mind, the steps to submit a change for a stable branch are as |
487 | follows: | 487 | follows: |
488 | 488 | ||
489 | 1. *Identify the bug or CVE to be fixed:* This information should be | 489 | #. *Identify the bug or CVE to be fixed:* This information should be |
490 | collected so that it can be included in your submission. | 490 | collected so that it can be included in your submission. |
491 | 491 | ||
492 | See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities` | 492 | See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities` |
493 | for details about CVE tracking. | 493 | for details about CVE tracking. |
494 | 494 | ||
495 | 2. *Check if the fix is already present in the master branch:* This will | 495 | #. *Check if the fix is already present in the master branch:* This will |
496 | result in the most straightforward path into the stable branch for the | 496 | result in the most straightforward path into the stable branch for the |
497 | fix. | 497 | fix. |
498 | 498 | ||
499 | a. *If the fix is present in the master branch --- submit a backport request | 499 | #. *If the fix is present in the master branch --- submit a backport request |
500 | by email:* You should send an email to the relevant stable branch | 500 | by email:* You should send an email to the relevant stable branch |
501 | maintainer and the mailing list with details of the bug or CVE to be | 501 | maintainer and the mailing list with details of the bug or CVE to be |
502 | fixed, the commit hash on the master branch that fixes the issue and | 502 | fixed, the commit hash on the master branch that fixes the issue and |
503 | the stable branches which you would like this fix to be backported to. | 503 | the stable branches which you would like this fix to be backported to. |
504 | 504 | ||
505 | b. *If the fix is not present in the master branch --- submit the fix to the | 505 | #. *If the fix is not present in the master branch --- submit the fix to the |
506 | master branch first:* This will ensure that the fix passes through the | 506 | master branch first:* This will ensure that the fix passes through the |
507 | project's usual patch review and test processes before being accepted. | 507 | project's usual patch review and test processes before being accepted. |
508 | It will also ensure that bugs are not left unresolved in the master | 508 | It will also ensure that bugs are not left unresolved in the master |
509 | branch itself. Once the fix is accepted in the master branch a backport | 509 | branch itself. Once the fix is accepted in the master branch a backport |
510 | request can be submitted as above. | 510 | request can be submitted as above. |
511 | 511 | ||
512 | c. *If the fix is unsuitable for the master branch --- submit a patch | 512 | #. *If the fix is unsuitable for the master branch --- submit a patch |
513 | directly for the stable branch:* This method should be considered as a | 513 | directly for the stable branch:* This method should be considered as a |
514 | last resort. It is typically necessary when the master branch is using | 514 | last resort. It is typically necessary when the master branch is using |
515 | a newer version of the software which includes an upstream fix for the | 515 | a newer version of the software which includes an upstream fix for the |