mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-06-02 13:29:49 +00:00
Code Issues Projects Releases Wiki Activity

contributor-guide: submit-changes: number instruction list in commit your changes

Browse Source 
... so that it's clear that you need to read and follow each and every
instruction in this list.

(From yocto-docs rev: 4799ffa5170a5f9e12350634bcdfca6f531ea937)

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit c628a489f081925fabaabb5acac6752251150269)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This commit is contained in:
Quentin Schulz
2025-09-18 12:24:44 +02:00
committed by Steve Sakoman
parent 794b42f01a
commit ffd5cd98d6
1 changed files with 58 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/contributor-guide/submit-changes.rst
+58 -58
View File
@@ -127,82 +127,82 @@ to add the upgraded version.
$ git commit -sa $ git commit -sa
- The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line #. The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
to your commit message. There is the same requirement for contributing to your commit message. There is the same requirement for contributing
to the Linux kernel. Adding such a line signifies that you, the to the Linux kernel. Adding such a line signifies that you, the
submitter, have agreed to the `Developer's Certificate of Origin 1.1 submitter, have agreed to the `Developer's Certificate of Origin 1.1
<https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__ <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__
as follows: as follows:
.. code-block:: none .. code-block:: none
Developer's Certificate of Origin 1.1 Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that: By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I (a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license have the right to submit it under the open source license
indicated in the file; or indicated in the file; or
(b) The contribution is based upon previous work that, to the best (b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that license and I have the right under that license to submit that
work with modifications, whether created in whole or in part work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated permitted to submit under a different license), as indicated
in the file; or in the file; or
(c) The contribution was provided directly to me by some other (c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified person who certified (a), (b) or (c) and I have not modified
it. it.
(d) I understand and agree that this project and the contribution (d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved. this project or the open source license(s) involved.
- Provide a single-line summary of the change and, if more #. Provide a single-line summary of the change and, if more
explanation is needed, provide more detail in the description of the explanation is needed, provide more detail in the description of the
commit. This summary is typically viewable in the "shortlist" of commit. This summary is typically viewable in the "shortlist" of
changes. Thus, providing something short and descriptive that changes. Thus, providing something short and descriptive that
gives the reader a summary of the change is useful when viewing a gives the reader a summary of the change is useful when viewing a
list of many commits. You should prefix this short description list of many commits. You should prefix this short description
with the recipe name (if changing a recipe), or else with the with the recipe name (if changing a recipe), or else with the
short form path to the file being changed. short form path to the file being changed.
.. note:: .. note::
To find a suitable prefix for the commit summary, a good idea To find a suitable prefix for the commit summary, a good idea
is to look for prefixes used in previous commits touching the is to look for prefixes used in previous commits touching the
same files or directories:: same files or directories::
git log --oneline <paths> git log --oneline <paths>
- For the commit description, provide detailed information #. For the commit description, provide detailed information
that describes what you changed, why you made the change, and the that describes what you changed, why you made the change, and the
approach you used. It might also be helpful if you mention how you approach you used. It might also be helpful if you mention how you
tested the change. Provide as much detail as you can in the commit tested the change. Provide as much detail as you can in the commit
description. description.
.. note:: .. note::
If the single line summary is enough to describe a simple If the single line summary is enough to describe a simple
change, the commit description can be left empty. change, the commit description can be left empty.
- If the change addresses a specific bug or issue that is associated #. If the change addresses a specific bug or issue that is associated
with a bug-tracking ID, include a reference to that ID in the body of the with a bug-tracking ID, include a reference to that ID in the body of the
commit message. For example, the Yocto Project uses a commit message. For example, the Yocto Project uses a
specific convention for bug references --- any commit that addresses specific convention for bug references --- any commit that addresses
a specific bug should use the following form for the body of the commit a specific bug should use the following form for the body of the commit
message. Be sure to use the actual bug-tracking ID from message. Be sure to use the actual bug-tracking ID from
Bugzilla for bug-id:: Bugzilla for bug-id::
single-line summary of change single-line summary of change
Fixes [YOCTO #bug-id] Fixes [YOCTO #bug-id]
detailed description of change detailed description of change
#. *Crediting contributors:* By using the ``git commit --amend`` command, #. *Crediting contributors:* By using the ``git commit --amend`` command,
you can add some tags to the commit description to credit other contributors you can add some tags to the commit description to credit other contributors