CaROS/poky
3
1
Fork 0
mirror of https://git.yoctoproject.org/git/poky synced 2026-01-01 13:58:04 +00:00
Code Issues Packages 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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

116
documentation/contributor-guide/submit-changes.rst
View File

@ -127,82 +127,82 @@ to add the upgraded version.
$ git commit -sa
- The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
to your commit message. There is the same requirement for contributing
to the Linux kernel. Adding such a line signifies that you, the
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>`__
as follows:
#. The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
to your commit message. There is the same requirement for contributing
to the Linux kernel. Adding such a line signifies that you, the
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>`__
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
have the right to submit it under the open source license
indicated in the file; or
(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
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
- Provide a single-line summary of the change and, if more
explanation is needed, provide more detail in the description of the
commit. This summary is typically viewable in the "shortlist" of
changes. Thus, providing something short and descriptive that
gives the reader a summary of the change is useful when viewing a
list of many commits. You should prefix this short description
with the recipe name (if changing a recipe), or else with the
short form path to the file being changed.
#. Provide a single-line summary of the change and, if more
explanation is needed, provide more detail in the description of the
commit. This summary is typically viewable in the "shortlist" of
changes. Thus, providing something short and descriptive that
gives the reader a summary of the change is useful when viewing a
list of many commits. You should prefix this short description
with the recipe name (if changing a recipe), or else with the
short form path to the file being changed.
.. note::
.. note::
To find a suitable prefix for the commit summary, a good idea
is to look for prefixes used in previous commits touching the
same files or directories::
To find a suitable prefix for the commit summary, a good idea
is to look for prefixes used in previous commits touching the
same files or directories::
git log --oneline <paths>
git log --oneline <paths>
- For the commit description, provide detailed information
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
tested the change. Provide as much detail as you can in the commit
description.
#. For the commit description, provide detailed information
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
tested the change. Provide as much detail as you can in the commit
description.
.. note::
.. note::
If the single line summary is enough to describe a simple
change, the commit description can be left empty.
If the single line summary is enough to describe a simple
change, the commit description can be left empty.
- 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
commit message. For example, the Yocto Project uses a
specific convention for bug references --- any commit that addresses
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
Bugzilla for bug-id::
#. 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
commit message. For example, the Yocto Project uses a
specific convention for bug references --- any commit that addresses
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
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,
you can add some tags to the commit description to credit other contributors