From 9baa7dfdfdb14a1d5d7b46e27cbd38599fc08643 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Thu, 18 Sep 2025 12:24:44 +0200 Subject: contributor-guide: submit-changes: number instruction list in commit your changes ... so that it's clear that you need to read and follow each and every instruction in this list. (From yocto-docs rev: 6dfef402b2785675870d513f4afeed6b7e7a4df1) Signed-off-by: Quentin Schulz Signed-off-by: Antonin Godard (cherry picked from commit c628a489f081925fabaabb5acac6752251150269) Signed-off-by: Antonin Godard Signed-off-by: Steve Sakoman --- documentation/contributor-guide/submit-changes.rst | 152 ++++++++++----------- 1 file changed, 76 insertions(+), 76 deletions(-) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 754c727aad..5bb3345cd0 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -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 - `__ - as follows: - - .. code-block:: none - - Developer's Certificate of Origin 1.1 - - 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 - - (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. - - (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. - - .. 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:: - - git log --oneline - - - 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:: - - 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:: - - single-line summary of change - - Fixes [YOCTO #bug-id] - - detailed description of change + #. 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 + `__ + as follows: + + .. code-block:: none + + Developer's Certificate of Origin 1.1 + + 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 + + (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. + + (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. + + .. 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:: + + git log --oneline + + #. 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:: + + 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:: + + single-line summary of change + + Fixes [YOCTO #bug-id] + + 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 -- cgit v1.2.3-54-g00ecf