From patchwork Fri Aug 18 17:09:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29139 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0433C7EE31 for ; Fri, 18 Aug 2023 17:10:29 +0000 (UTC) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by mx.groups.io with SMTP id smtpd.web10.77.1692378621156587588 for ; Fri, 18 Aug 2023 10:10:21 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=FN62TxLW; spf=pass (domain: bootlin.com, ip: 217.70.183.193, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id D8BF2240004; Fri, 18 Aug 2023 17:10:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378619; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ndD9zW9JqTqCfk3DCMRe/mpBnoMFSaIp2CgQTVVzm4M=; b=FN62TxLW9t8DopTd1yHCnT4jlIAqKxbbdDHII90oP8keV7BMI0JWDiw9rpGTMG4HhkNAT4 Qfoiqz/EtBlJbgC5ODlpzWn0QIAERC64lzqBOq/VsukgA0V5H/o2vvoK/76/WzexZSeykV Yju6FQXG/0Hfb5CzqoSnPHlLsSyB+ZyK3pn6MrlOXrT//VouuGlD4vNalsZvSYPbK0aszk ICWfxcJ47AVu48fcx0sqD6cQs2w7IIUi33P9IkLn6uZ8lOGwQMiW9Hmjk3jf+lqvYIvxEm fzbNdGPlPqWZwtRSXQBYTAHuUaznmRq1oC6hJfhE4gfhKi2dIAqD2iXoR7qFFw== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 01/10] contributor-guide: move to 2nd place in top menu Date: Fri, 18 Aug 2023 19:09:56 +0200 Message-Id: <20230818171005.92381-2-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:29 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4166 From: Michael Opdenacker To give it more visibility Signed-off-by: Michael Opdenacker --- documentation/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/index.rst b/documentation/index.rst index 4d0231503d..3fef1704a4 100644 --- a/documentation/index.rst +++ b/documentation/index.rst @@ -26,6 +26,7 @@ Welcome to the Yocto Project Documentation :caption: Manuals Overview and Concepts Manual + Contributor Guide Reference Manual Board Support Package (BSP) Developer's guide Development Tasks Manual @@ -34,7 +35,6 @@ Welcome to the Yocto Project Documentation Application Development and the Extensible SDK (eSDK) Toaster Manual Test Environment Manual - Contributor Guide bitbake .. toctree:: From patchwork Fri Aug 18 17:09:57 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29138 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4B4AC71159 for ; Fri, 18 Aug 2023 17:10:29 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx.groups.io with SMTP id smtpd.web11.76.1692378623871394470 for ; Fri, 18 Aug 2023 10:10:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=WExjjy8P; spf=pass (domain: bootlin.com, ip: 217.70.183.195, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id B81C660002; Fri, 18 Aug 2023 17:10:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NC8Son5TEUXilC/ZzNxwNgYzT6Q18DYvAhdeNq1fYJg=; b=WExjjy8PNKUvIOryRhdYMUMWKk8w/xT7UKsdhE2lWz09kqrv0lgBkT0nwOpWo1p9twwEVI maweTYAkoAmdlj40Zom0RjCdXA+XIz0r0EK+A1h3P3yJodkWIPnmXOpkkelAxe0UkJTqLJ UXlFwDnhPKrglHHurAbJWfsQ/8LRKLS1JA17xCtNHXAUMtcIydmDP5eq9Zkk6vlv7GGo2B 8nuW43g9oix3qgOyWc0ZUHviGdb/iKZqAnUS5DGE/d7gOLWgaSgZ/exv2LE3rY+bmzyPGn FlGZOCsWYlYuUIVu5ildNiCmMVxZv6uGmHM+UQwCUEv2sU5bWjcvH4dthZzqlA== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 02/10] contributor-guide: submit-changes: simplify note Date: Fri, 18 Aug 2023 19:09:57 +0200 Message-Id: <20230818171005.92381-3-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:29 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4167 From: Michael Opdenacker Signed-off-by: Michael Opdenacker --- documentation/contributor-guide/submit-changes.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 3f6d2db96c..533aab5b83 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -226,9 +226,8 @@ So, for each identified change: .. note:: - You do not need to provide a more detailed explanation of a - change if the change is minor to the point of the single line - summary providing all the information. + If the single line summary is enough to describe a simple + change, the body of the commit message 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 your From patchwork Fri Aug 18 17:09:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29140 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1649C7EE32 for ; Fri, 18 Aug 2023 17:10:29 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx.groups.io with SMTP id smtpd.web10.79.1692378627335498056 for ; Fri, 18 Aug 2023 10:10:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=oTo2zyki; spf=pass (domain: bootlin.com, ip: 217.70.183.196, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 3433EE0003; Fri, 18 Aug 2023 17:10:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dy/RCcIEai3jalaNgU9kjOEUniKR3Ep3tDT1Qws4oJE=; b=oTo2zykiWIabMSvua6okTCZ27ISUUV/LauDstekpSLjpNjny4eEjjPB5w39uv8ZFSaYSvN NkhYKYh6JZgbP/7bkD7M4BFi5hLGhSTJ11tikMOPTTu1lZJCLzbf1BiigtP7vrIS4agxXq KMNiVUIxDVNfQoxPwCW1YA/UosJcsND1jHIzNk/OYmN7xjXe6A3+8Pd02aNfDkSK8LwdwZ 0g1a0tu/JszMeLpFRFaA9HCbFsISndoWMDthmlXW6WHRuB0MB8PzXWnsH2I8x+Jnk3P+Cu waBh4iN5TezQENu9Fgj8iUD1s3/RLemorqTBfgQnylnhtlQKGJC/SycW1vOdag== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 03/10] contributor-guide: identify component: provide link to repositories Date: Fri, 18 Aug 2023 19:09:58 +0200 Message-Id: <20230818171005.92381-4-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:29 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4168 From: Michael Opdenacker Signed-off-by: Michael Opdenacker --- documentation/contributor-guide/identify-component.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/documentation/contributor-guide/identify-component.rst b/documentation/contributor-guide/identify-component.rst index ba7c998888..a28391a66a 100644 --- a/documentation/contributor-guide/identify-component.rst +++ b/documentation/contributor-guide/identify-component.rst @@ -22,8 +22,10 @@ issues can be reported in the :yocto_bugs:`Yocto Project Bugzilla <>`. The where questions can be sent if you can’t work out where something should go. :term:`Poky` is a commonly used “combination” repository where multiple -components have been combined (``bitbake``, ``openembedded-core``, -``meta-yocto`` and ``yocto-docs``). Patches should be submitted against -the appropriate individual component rather than :term:`Poky` itself as -detailed in the appropriate ``README`` file. +components have been combined (:oe_git:`bitbake `, +:oe_git:`openembedded-core `, +:yocto_git:`meta-yocto ` and +:yocto_git:`yocto-docs `). Patches should be submitted against the +appropriate individual component rather than :term:`Poky` itself as detailed in +the appropriate ``README`` file. From patchwork Fri Aug 18 17:09:59 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29142 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 376F4C7EE39 for ; Fri, 18 Aug 2023 17:10:40 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx.groups.io with SMTP id smtpd.web10.81.1692378631309539040 for ; Fri, 18 Aug 2023 10:10:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=YVtWpkgw; spf=pass (domain: bootlin.com, ip: 217.70.183.196, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 95A44E0004; Fri, 18 Aug 2023 17:10:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378629; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VL+F+vDFiaGyd1qEJjI5U0A4wzYZl17scbep1w9xRko=; b=YVtWpkgw3AhoMKuNYOC6KjGHyVAjC6vGR6vlD/xW1filOAXKwqxKQrEsw796gc4TUuEzPz wkiVnF+oz/aAhrL2yY2GlmhMT6C8yw39qZBH4/A5+G7DfvXkKa2VKWUs3dKE5Qh/nFAUAc VACMrc5fCOLcxvIAMXn76sF3hiQymmb3ivCUxwUnb7/iJE0wK21z6+sgQKDAQTZrr3CN7i qPLgHzYHrp9wvx/0SG1QM0dB23YOjueCqq7LWaNuTF/SpMqTV5C2puoJoeXAmCKJ5zipW2 NPo2Vrw6R7r+ksInUVF3Ka0Wq1KH0lqs5C1iA9uIUXqYq+YoEfMQMARTk57CqA== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 04/10] contributor-guide: submit-changes: detail commit and patch creation Date: Fri, 18 Aug 2023 19:09:59 +0200 Message-Id: <20230818171005.92381-5-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:40 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4169 From: Michael Opdenacker Add missing steps and try to provide better guidance and more modern solutions, for example keeping track of the cover letter in the branch itself. Also add subsections to divide the instructions into easier to understand parts. Signed-off-by: Michael Opdenacker --- .../contributor-guide/submit-changes.rst | 148 +++++++++++++----- 1 file changed, 110 insertions(+), 38 deletions(-) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 533aab5b83..314b41bb63 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -140,7 +140,34 @@ The following sections provide procedures for submitting changes. Preparing Changes for Submission ================================ -The first thing to do is to create a new branch in your local Git repository +Set up Git +---------- + +The first thing to do is to install Git packages. Here is an example +on Debian and Ubuntu:: + + sudo aptitude install git-core git-email + +Then, you need to set a name and e-mail address that Git will +use to identify your commits:: + + git config --global user.name "Ada Lovelace" + git config --global user.email "ada.lovelace@gmail.com" + +Clone the Git repository for the component to modify +---------------------------------------------------- + +After identifying the component to modify as described in the +":doc:`../contributor-guide/identify-component`" section, clone the +corresponding Git repository. Here is an example for OpenEmbedded-Core:: + + git clone https://git.openembedded.org/openembedded-core + cd openembedded-core + +Create a new branch +------------------- + +Then, create a new branch in your local Git repository for your changes, starting from the reference branch in the upstream repository (often called ``master``):: @@ -150,26 +177,37 @@ repository (often called ``master``):: If you have completely unrelated sets of changes to submit, you should even create one branch for each set. -Then, in each branch, you should group your changes into small, controlled and +Implement and commit changes +---------------------------- + +In each branch, you should group your changes into small, controlled and isolated ones. Keeping changes small and isolated aids review, makes merging/rebasing easier and keeps the change history clean should anyone need to refer to it in future. To this purpose, you should create *one Git commit per change*, corresponding to each of the patches you will eventually submit. -So, for each identified change: +See `further guidance `__ +in the Linux kernel documentation if needed. -#. *Stage Your Change:* Stage your change by using the ``git add`` - command on each file you modified. +#. *Stage Your Changes:* Stage your changes by using the ``git add`` + command on each file you modified. If you want to stage all the + files you modified, you can even use the ``git add -A`` command. -#. *Commit Your Change:* Commit the change by using the ``git commit`` - command. Make sure your commit information follows standards by - following these accepted conventions: +#. *Commit Your Changes:* This is when you can create separate commits. For + each commit to create, use the ``git commit -s`` command with the files + or directories you want to include in the commit:: - - Be sure to include a "Signed-off-by:" line in the same style as - required by the Linux kernel. This can be done by using the - ``git commit -s`` command. Adding this line signifies that you, - the submitter, have agreed to the `Developer's Certificate of Origin 1.1 + $ git commit -s file1 file2 dir1 dir2 ... + + To include **a**\ ll staged files:: + + $ 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: @@ -241,39 +279,74 @@ So, for each identified change: detailed description of change -Using Email to Submit Patches -============================= +Creating Patches +================ -Depending on the components changed, you need to submit the email to a -specific mailing list. For some guidance on which mailing list to use, -see the ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" -section above. +Here is the general procedure on how to create patches to be sent through email: + +#. *Describe the Changes in your Branch:* If you have more than one commit + in your branch, it's recommended to provide a cover letter describing + the series of patches you are about to send. + + For this purpose, a good solution is to store the cover letter contents + in the branch itself:: -Here is the general procedure on how to create and submit patches through email: + git branch --edit-description -#. *Generate Patches for your Branch:* The ``git format-patch`` command for + This will open a text editor to fill in the description for your + changes. This description can be updated when necessary and will + be used by Git to create the cover letter together with the patches. + + It is recommended to start this description with a title line which + will serve a the subject line for the cover letter. + +#. *Generate Patches for your Branch:* The ``git format-patch`` command will generate patch files for each of the commits in your branch. You need - to pass the reference branch your branch starts from:: + to pass the reference branch your branch starts from. + + If you branch didn't need a description in the previous step:: $ git format-patch - After the command is run, the current directory contains numbered - ``.patch`` files for the commits in your branch. + If you filled a description for your branch, you will want to generate + a cover letter too:: - If you have more than one patch, you should also use the ``--cover`` - option with the command, which generates a cover letter as the first - "patch" in the series. You can then edit the cover letter to provide - a description for the series of patches. Run ``man git-format-patch`` - for details about this command. + $ git format-patch --cover-letter --cover-from-description=auto -#. *Send the patches via email:* Send the patches to the recipients and - relevant mailing lists by using the ``git send-email`` command. + After the command is run, the current directory contains numbered + ``.patch`` files for the commits in your branch. If you have a cover + letter, it will be in the ``0000-cover-letter.patch``. .. note:: - In order to use ``git send-email``, you must have the proper Git packages - installed on your host. - For Ubuntu, Debian, and Fedora the package is ``git-email``. + The ``--cover-from-description=auto`` option makes ``git format-patch`` + use the first paragraph of the branch description as the cover + letter title. Another possibility, which is easier to remember, is to pass + only the ``--cover-letter`` option, but you will have to edit the + subject line manually every time you generate the patches. + + See the `git format-patch manual page `__ + for details. + +#. *Review each of the Patch Files:* This final review of the patches + before sending them often allows to view your changes from a different + perspective and discover defects such as typos, spacing issues or lines + or even files that you didn't intend to modify. This review should + include the cover letter patch too. + + If necessary, rework your commits as described in + ":ref:`contributor-guide/submit-changes:take patch review into account`". + +Sending the Patches via Email +============================= + +Depending on the components changed, you need to submit the email to a +specific mailing list. For some guidance on which mailing list to use, +see the ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" +section above. + +#. *Send the patches via email:* Send the patches to the recipients and + relevant mailing lists by using the ``git send-email`` command. The ``git send-email`` command sends email by using a local or remote Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or @@ -420,8 +493,8 @@ have been followed: $ poky/scripts/create-pull-request -h $ poky/scripts/send-pull-request -h -Responding to Patch Review -========================== +Take Patch Review into Account +============================== You may get feedback on your submitted patches from other community members or from the automated patchtest service. If issues are identified in your @@ -494,9 +567,8 @@ follows: a newer version of the software which includes an upstream fix for the issue or when the issue has been fixed on the master branch in a way that introduces backwards incompatible changes. In this case follow the - steps in ":ref:`contributor-guide/submit-changes:preparing changes for submission`" and - ":ref:`contributor-guide/submit-changes:using email to submit patches`" - but modify the subject header of your patch + steps in ":ref:`contributor-guide/submit-changes:preparing changes for submission`" + and in the following sections but modify the subject header of your patch email to include the name of the stable branch which you are targetting. This can be done using the ``--subject-prefix`` argument to ``git format-patch``, for example to submit a patch to the dunfell From patchwork Fri Aug 18 17:10:00 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29143 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AF97C7EE31 for ; Fri, 18 Aug 2023 17:10:40 +0000 (UTC) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by mx.groups.io with SMTP id smtpd.web11.80.1692378634866086132 for ; Fri, 18 Aug 2023 10:10:35 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=NJDchDXZ; spf=pass (domain: bootlin.com, ip: 217.70.183.200, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 3461620005; Fri, 18 Aug 2023 17:10:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378633; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=27FEB14je1CohoaO1hZI2qByOKZ7JF9mWdHYQBQrtF4=; b=NJDchDXZpMUzdSXPDya4cM363aZphOnFXgrF3KC5pFOV0s47fjEmpzMoWdKLCP/2JFdzUt aePIHZqb3skKVkClGXxZu3nJL7wAXheaXpnEkW/Pz8iQuNQSh6/gC4z0JrP6QzU0DzZKVJ JezwHXnH6YwBfbksbkpZiBu2nJ8Os7/ZZ/X9+V7RQugzu9s7gLWgb9d0GP3Zw0qfG9PWyY 2It/sRoGu94v7BgSKK531aiO5FU5EUos+nSVeGHK1o1+wBc9VVyymEiEaVoL4wS/SmJtxB aQ/9NJf4KWW6O+UY6Q87u9m46V09AqELFMPSjs7ToXQF3P8AzK59dyRNdEfJ0g== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 05/10] contributor-guide: submit-changes: develop sending patches section Date: Fri, 18 Aug 2023 19:10:00 +0200 Message-Id: <20230818171005.92381-6-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:40 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4170 From: Michael Opdenacker Signed-off-by: Michael Opdenacker --- .../contributor-guide/submit-changes.rst | 29 +++++++++++++------ 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 314b41bb63..afed30717b 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -340,6 +340,25 @@ Here is the general procedure on how to create patches to be sent through email: Sending the Patches via Email ============================= +Using Git to Send Patches +------------------------- + +To submit patches through email, it is very important that you send them +without any whitespace or HTML formatting that either you or your mailer +introduces. The maintainer that receives your patches needs to be able +to save and apply them directly from your emails, using the ``git am`` +command. + +Using the ``git send-email`` command is the only error-proof way of +sending your patches using email since there is no risk of compromising +whitespace in the body of the message, which can occur when you use +your own mail client. It will also properly include your patches +as inline attachments, which is not easy to do with standard e-mail +clients without breaking lines. + +Setting up Git to Send Email +---------------------------- + Depending on the components changed, you need to submit the email to a specific mailing list. For some guidance on which mailing list to use, see the ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" @@ -350,15 +369,7 @@ section above. The ``git send-email`` command sends email by using a local or remote Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or - through a direct ``smtp`` configuration in your Git ``~/.gitconfig`` - file. If you are submitting patches through email only, it is very - important that you submit them without any whitespace or HTML - formatting that either you or your mailer introduces. The maintainer - that receives your patches needs to be able to save and apply them - directly from your emails. A good way to verify that what you are - sending will be applicable by the maintainer is to do a dry run and - send them to yourself and then save and apply them as the maintainer - would. + through a direct ``smtp`` configuration in your Git ``~/.gitconfig`` file. The ``git send-email`` command is the preferred method for sending your patches using email since there is no risk of compromising From patchwork Fri Aug 18 17:10:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29141 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37C1EC7EE3A for ; Fri, 18 Aug 2023 17:10:40 +0000 (UTC) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by mx.groups.io with SMTP id smtpd.web11.84.1692378637182932716 for ; Fri, 18 Aug 2023 10:10:37 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=iE0c2U4U; spf=pass (domain: bootlin.com, ip: 217.70.183.193, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 5A7BB240003; Fri, 18 Aug 2023 17:10:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378635; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pIUsFLqe59fH18WAGj2qw1pJ/WJS8xNh/bIqL02Ob08=; b=iE0c2U4UBFmrDU71Wzz9WLNHITAFDM6MQPIwCSjpZe69hyhveB6Gem/P9q3vLIcv7VQMld uutIyBfSgzVZkl7ySLw04J8VrnwAEcw7St+YXIEyPCI8Hq5XsOHHDM/ND0PfGkhUvq30Vi DFbkcJzggnjDW8o9VKl1AU1MbQTVCGh5ut8rbtI80SAqbQSg7yfPWrjJYPzpMdE9JRDBOw UK5wNsmnEgE8E/ql/U8r3lOc/0zOQgUmKVbVWvzeaikiHXYfPaOhmWSoeItW+cv9lSeVaj BSlP6tY+lHimbgq2Mk6q00kO8wIs32wpbvwmKeLlF9MjA0/4fud0IZqRQYVEFA== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 06/10] manuals: README: update list of manuals Date: Fri, 18 Aug 2023 19:10:01 +0200 Message-Id: <20230818171005.92381-7-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:40 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4171 From: Michael Opdenacker Signed-off-by: Michael Opdenacker --- documentation/README | 8 ++-- .../contributor-guide/submit-changes.rst | 48 +++++++++++++++---- 2 files changed, 43 insertions(+), 13 deletions(-) diff --git a/documentation/README b/documentation/README index e8aed86eb4..4d31036e69 100644 --- a/documentation/README +++ b/documentation/README @@ -34,16 +34,18 @@ Manual Organization Here the folders corresponding to individual manuals: +* brief-yoctoprojectqs - Yocto Project Quick Start * overview-manual - Yocto Project Overview and Concepts Manual -* sdk-manual - Yocto Project Software Development Kit (SDK) Developer's Guide. +* contributor-guide - Yocto Project and OpenEmbedded Contributor Guide +* ref-manual - Yocto Project Reference Manual * bsp-guide - Yocto Project Board Support Package (BSP) Developer's Guide * dev-manual - Yocto Project Development Tasks Manual * kernel-dev - Yocto Project Linux Kernel Development Manual -* ref-manual - Yocto Project Reference Manual -* brief-yoctoprojectqs - Yocto Project Quick Start * profile-manual - Yocto Project Profiling and Tracing Manual +* sdk-manual - Yocto Project Software Development Kit (SDK) Developer's Guide. * toaster-manual - Toaster User Manual * test-manual - Yocto Project Test Environment Manual +* migration-guides - Yocto Project Release and Migration Notes Each folder is self-contained regarding content and figures. diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index afed30717b..aeef2cc90a 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -349,16 +349,48 @@ introduces. The maintainer that receives your patches needs to be able to save and apply them directly from your emails, using the ``git am`` command. -Using the ``git send-email`` command is the only error-proof way of -sending your patches using email since there is no risk of compromising -whitespace in the body of the message, which can occur when you use -your own mail client. It will also properly include your patches -as inline attachments, which is not easy to do with standard e-mail -clients without breaking lines. +Using the ``git send-email`` command is the only error-proof way of sending +your patches using email since there is no risk of compromising whitespace +in the body of the message, which can occur when you use your own mail +client. It will also properly include your patches as *inline attachments*, +which is not easy to do with standard e-mail clients without breaking lines. +If you used your regular e-mail client and shared your patches as regular +attachments, reviewers wouldn't be able to quote specific sections of your +changes and make comments about them. Setting up Git to Send Email ---------------------------- +The ``git send-email`` command can send email by using a local or remote +Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or +through a direct SMTP configuration in your Git ``~/.gitconfig`` file. + +Here are the settings for letting ``git send-email`` send e-mail through your +regular STMP server, using a Google Mail account as an example:: + + git config --global sendemail.smtpserver smtp.gmail.com + git config --global sendemail.smtpserverport 587 + git config --global sendemail.smtpencryption tls + git config --global sendemail.smtpuser ada.lovelace@gmail.com + git config --global sendemail.smtppass = XXXXXXXX + +These settings will appear in the ``.gitconfig`` file in your home directory. + +If you neither can use a local MTA nor SMTP, make sure you use an email client +that does not touch the message (turning spaces in tabs, wrapping lines, etc.). +A good mail client to do so is Pine (or Alpine) or Mutt. For more +information about suitable clients, see `Email clients info for Linux +`__ +in the Linux kernel sources. + +If you use such clients, just include the patch in the body of your email. + +Subscribing to Mailing Lists +---------------------------- + +Sending Patches via Email +------------------------- + Depending on the components changed, you need to submit the email to a specific mailing list. For some guidance on which mailing list to use, see the ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" @@ -367,10 +399,6 @@ section above. #. *Send the patches via email:* Send the patches to the recipients and relevant mailing lists by using the ``git send-email`` command. - The ``git send-email`` command sends email by using a local or remote - Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or - through a direct ``smtp`` configuration in your Git ``~/.gitconfig`` file. - The ``git send-email`` command is the preferred method for sending your patches using email since there is no risk of compromising whitespace in the body of the message, which can occur when you use From patchwork Fri Aug 18 17:10:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29147 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34952C88CB9 for ; Fri, 18 Aug 2023 17:10:50 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx.groups.io with SMTP id smtpd.web10.1.1692378640817453021 for ; Fri, 18 Aug 2023 10:10:41 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=a+J5Up80; spf=pass (domain: bootlin.com, ip: 217.70.183.196, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 194F2E0004; Fri, 18 Aug 2023 17:10:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378637; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1QaLzL9pGIT6c0wYBhBlXq3fU6FWZA+HuSCTp1Kgb/0=; b=a+J5Up80+9q3rpvd0oP6hIiVIk4aqVoKRnPfuzsvOe+Aw57ZH6z5+mYrCmQxGx2giFqyoi /m6/IXDx5VQRGwc1tAsNjNgWGpMIdV2vlhG1PPVlRcOmQdWpcN6xtEoPR4yf/nO1TXDGaX smCWov0yMWDjVYnEMslFltGDdGHN5THjJHPVnesLvS2IAlMIVMl9gAR9mRBl9xi3vDGcfQ p+VlQ/K4+aXjDdcdgEWkk/RjonUefJ69U0eFQS1ayKKHhLrJm9J1WdCcR8ayMevHbe1ygE oQEhCAXvoSPXyhqlDFhcj0/AhCR61I5EUPcOhJmISwplHvA98Har6c+8hr4uBg== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 07/10] contributor-guide: submit-changes: reorganize and develop sections Date: Fri, 18 Aug 2023 19:10:02 +0200 Message-Id: <20230818171005.92381-8-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:50 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4172 From: Michael Opdenacker In particular, develop the sections about sending patches. Reorder sections for a more logical flow. Remove unnecessary or duplicate details too. Signed-off-by: Michael Opdenacker --- .../contributor-guide/submit-changes.rst | 402 ++++++++++++------ 1 file changed, 262 insertions(+), 140 deletions(-) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index aeef2cc90a..3098a76a6c 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -48,95 +48,6 @@ test user contributions before they hit the mailing lists and also at better documenting how to use such workflows since we recognise that whilst this was common knowledge a decade ago, it might not be as familiar now. -Finding a Suitable Mailing List -=============================== - -The Yocto Project and OpenEmbedded use a mailing list and a patch-based -workflow that is similar to the Linux kernel but contains important -differences. In general, there is a mailing list through which you can submit -patches. You should send patches to the appropriate mailing list so that they -can be reviewed and merged by the appropriate maintainer. The specific mailing -list you need to use depends on the location of the code you are -changing. Each component (e.g. layer) should have a ``README`` file that -indicates where to send the changes and which process to follow. - -You can send the patches to the mailing list using whichever approach you -feel comfortable with to generate the patches. Once sent, the patches are -usually reviewed by the community at large. If somebody has concerns -any of the the patches, they will usually voice their concern over the mailing -list. If patches do not receive any negative reviews, the maintainer -of the affected layer typically takes them, tests them, and then -based on successful testing, merges them. - -The "poky" repository, which is the Yocto Project's reference build -environment, is a hybrid repository that contains several individual -pieces (e.g. BitBake, Metadata, documentation, and so forth) built using -the combo-layer tool. The upstream location used for submitting changes -varies by component: - -- *Core Metadata:* Send your patches to the - :oe_lists:`openembedded-core ` - mailing list. For example, a change to anything under the ``meta`` or - ``scripts`` directories should be sent to this mailing list. - -- *BitBake:* For changes to BitBake (i.e. anything under the - ``bitbake`` directory), send your patches to the - :oe_lists:`bitbake-devel ` - mailing list. - -- *"meta-\*" trees:* These trees contain Metadata. Use the - :yocto_lists:`poky ` mailing list. - -- *Documentation*: For changes to the Yocto Project documentation, use the - :yocto_lists:`docs ` mailing list. - -For changes to other layers hosted in the Yocto Project source -repositories (i.e. ``yoctoproject.org``) and tools use the -:yocto_lists:`yocto ` general mailing list. - -.. note:: - - Sometimes a layer's documentation specifies to use a particular - mailing list. If so, use that list. - -For additional recipes that do not fit into the core Metadata, you -should determine which layer the recipe should go into and submit the -changes in the manner recommended by the documentation (e.g. the -``README`` file) supplied with the layer. If in doubt, please ask on the -:yocto_lists:`yocto ` general mailing list or on the -:oe_lists:`openembedded-devel ` mailing list. - -You can also push changes upstream and request a maintainer to pull the -changes into the component's upstream repository. You do this by pushing -to a contribution repository that is upstream. See the -":ref:`overview-manual/development-environment:git workflows and the yocto project`" -section in the Yocto Project Overview and Concepts Manual for additional -concepts on working in the Yocto Project development environment. - -Maintainers commonly use ``-next`` branches to test submissions prior to -merging patches. Thus, you can get an idea of the status of a patch based on -whether the patch has been merged into one of these branches. The commonly -used testing branches for OpenEmbedded-Core are as follows: - -- *openembedded-core "master-next" branch:* This branch is part of the - :oe_git:`openembedded-core ` repository and contains - proposed changes to the core metadata. - -- *poky "master-next" branch:* This branch is part of the - :yocto_git:`poky ` repository and combines proposed - changes to BitBake, the core metadata and the poky distro. - -Similarly, stable branches maintained by the project may have corresponding -``-next`` branches which collect proposed changes. For example, -``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next`` -branches in both the "openembdedded-core" and "poky" repositories. - -Other layers may have similar testing branches but there is no formal -requirement or standard for these so please check the documentation for the -layers you are contributing to. - -The following sections provide procedures for submitting changes. - Preparing Changes for Submission ================================ @@ -279,6 +190,32 @@ in the Linux kernel documentation if needed. 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 + to the change: + + - ``Reported-by``: name and email of a person reporting a bug + that your commit is trying to fix. This is a good practice + to encourage people to go on reporting bugs and let them + know that their reports are taken into account. + + - ``Suggested-by``: name and email of a person to credit for the + idea of making the change. + + - ``Tested-by``, ``Reviewed-by``: name and email for people having + tested your changes or reviewed their code. These fields are + usually added by the maintainer accepting a patch, or by + yourself if you submitted your patches to early reviewers, + or are submitting an unmodified patch again as part of a + new iteration of your patch series. + + - ``CC:`` Name and email of people you want to send a copy + of your changes to. This field will be used by ``git send-email``. + + See `more guidance about using such tags + `__ + in the Linux kernel documentation. + Creating Patches ================ @@ -335,7 +272,7 @@ Here is the general procedure on how to create patches to be sent through email: include the cover letter patch too. If necessary, rework your commits as described in - ":ref:`contributor-guide/submit-changes:take patch review into account`". + ":ref:`contributor-guide/submit-changes:taking patch review into account`". Sending the Patches via Email ============================= @@ -385,43 +322,156 @@ in the Linux kernel sources. If you use such clients, just include the patch in the body of your email. -Subscribing to Mailing Lists ----------------------------- +Finding a Suitable Mailing List +------------------------------- + +You should send patches to the appropriate mailing list so that they can be +reviewed by the right contributors and merged by the appropriate maintainer. +The specific mailing list you need to use depends on the location of the code +you are changing. Each component (e.g. layer) should have a ``README`` file +that indicates where to send the changes and which process to follow. + +If people have concerns with any of the patches, they will usually voice +their concern over the mailing list. If patches do not receive any negative +reviews, the maintainer of the affected layer typically takes them, tests them, +and then based on successful testing, merges them. + +The "poky" repository, which is the Yocto Project's reference build +environment, is a hybrid repository that contains several individual +pieces (e.g. BitBake, Metadata, documentation, and so forth) built using +the combo-layer tool. The upstream location used for submitting changes +varies by component: + +- *Core Metadata:* Send your patches to the + :oe_lists:`openembedded-core ` + mailing list. For example, a change to anything under the ``meta`` or + ``scripts`` directories should be sent to this mailing list. + +- *BitBake:* For changes to BitBake (i.e. anything under the + ``bitbake`` directory), send your patches to the + :oe_lists:`bitbake-devel ` + mailing list. + +- *"meta-\*" trees:* These trees contain Metadata. Use the + :yocto_lists:`poky ` mailing list. + +- *Documentation*: For changes to the Yocto Project documentation, use the + :yocto_lists:`docs ` mailing list. + +For changes to other layers hosted in the Yocto Project source +repositories (i.e. ``yoctoproject.org``) and tools use the +:yocto_lists:`yocto ` general mailing list. + +.. note:: + + Sometimes a layer's documentation specifies to use a particular + mailing list. If so, use that list. + +For additional recipes that do not fit into the core Metadata, you +should determine which layer the recipe should go into and submit the +changes in the manner recommended by the documentation (e.g. by the +``README`` file) supplied with the layer. If in doubt, please ask on the +:yocto_lists:`yocto ` general mailing list or on the +:oe_lists:`openembedded-devel ` mailing list. + +Subscribing to the Mailing List +------------------------------- + +After identifying the right mailing list to use, you will have to subscribe to +it if you haven't done it yet. + +If you attempt to send patches to a list you haven't subscribed to, your email +will be returned as undelivered. + +However, if you don't want to be receive all the messages sent to a mailing list, +you can set your subscription to "no email". You will still be a subscriber able +to send messages, but you won't receive any e-mail. If people reply to your message, +their e-mail clients will default to including your email address in the +conversation anyway. + +Anyway, you'll also be able to access the new messages on mailing list archives, +either through a web browser, or for the lists archived on https://lore.kernelorg, +through an individual newsgroup feed or a git repository. Sending Patches via Email ------------------------- -Depending on the components changed, you need to submit the email to a -specific mailing list. For some guidance on which mailing list to use, -see the ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" -section above. +At this stage, you are ready to send your patches via email. Here's the +typical usage of ``git send-email``:: -#. *Send the patches via email:* Send the patches to the recipients and - relevant mailing lists by using the ``git send-email`` command. + git send-email --to *.patch - The ``git send-email`` command is the preferred method for sending - your patches using email since there is no risk of compromising - whitespace in the body of the message, which can occur when you use - your own mail client. The command also has several options that let - you specify recipients and perform further editing of the email - message. Here's a typical usage of this command:: +Then, review each subject line and list of recipients carefully, and then +and then allow the command to send each message. - git send-email --to *.patch +You will see that ``git send-email`` will automatically copy the people listed +in any commit tags such as ``Signed-off-by`` or ``Reported-by``. - Run ``man git-send-email`` for more details about this command. +In case you are sending patches for :oe_git:`meta-openembedded ` +or any layer other than :oe_git:`openembedded-core `, +please add the appropriate prefix so that it is clear which layer the patch is intended +to be applied to:: -The Yocto Project uses a `Patchwork instance `__ -to track the status of patches submitted to the various mailing lists and to -support automated patch testing. Each submitted patch is checked for common -mistakes and deviations from the expected patch format and submitters are -notified by ``patchtest`` if such mistakes are found. This process helps to -reduce the burden of patch review on maintainers. + git send-email --subject-prefix="meta-oe][PATCH" ... .. note:: - This system is imperfect and changes can sometimes get lost in the flow. - Asking about the status of a patch or change is reasonable if the change - has been idle for a while with no feedback. + It is actually possible to send patches without generating them + first. However, make sure you have reviewed your changes carefully + because ``git send-email`` will just show you the title lines of + each patch. + + Here's a command you can use if you just have one patch in your + branch:: + + git send-email --to -1 + + If you have multiple patches and a cover letter, you can send + patches for all the commits between the reference branch + and the tip of your branch:: + + git send-email --cover-letter --cover-from-description=auto --to -M + +See the `git send-email manual page `__ +for details. + +Troubleshooting Email Issues +---------------------------- + +Fixing your From identity +~~~~~~~~~~~~~~~~~~~~~~~~~ + +We have a frequent issue with contributors whose patches are received through +a ``From`` field which doesn't match the ``Signed-off-by`` information. Here is +a typical example for people sending from a domain name with :wikipedia:`DMARC`:: + + From: "Linus Torvalds via lists.openembedded.org " + +This ``From`` field is used by ``git am`` to recreate commits with the right +author name. The following will ensure that your e-mails have an additional +``From`` field at the beginning of the Email body, and therefore that +maintainers accepting your patches don't have to fix commit author information +manually:: + + git config --global sendemail.from "linus.torvalds@kernel.org" + +The ``sendemail.from`` should match your ``user.email`` setting, +which appears in the ``Signed-off-by`` line of your commits. + +Streamlining git send-email usage +--------------------------------- + +If you want to save time and not be forced to remember the right options to use +with ``git send-email``, you can use Git configuration settings. + +- To set the right mailing list address for a given repository:: + + git config --local sendemail.to openembedded-devel@lists.openembedded.org + +- If the mailing list requires a subject prefix for the layer + (this only works when the repository only contains one layer):: + + git config --local format.subjectprefix "meta-something][PATCH" Using Scripts to Push a Change Upstream and Request a Pull ========================================================== @@ -532,28 +582,6 @@ have been followed: $ poky/scripts/create-pull-request -h $ poky/scripts/send-pull-request -h -Take Patch Review into Account -============================== - -You may get feedback on your submitted patches from other community members -or from the automated patchtest service. If issues are identified in your -patch then it is usually necessary to address these before the patch will be -accepted into the project. In this case you should amend the patch according -to the feedback and submit an updated version to the relevant mailing list, -copying in the reviewers who provided feedback to the previous version of the -patch. - -The patch should be amended using ``git commit --amend`` or perhaps ``git -rebase`` for more expert git users. You should also modify the ``[PATCH]`` -tag in the email subject line when sending the revised patch to mark the new -iteration as ``[PATCH v2]``, ``[PATCH v3]``, etc as appropriate. This can be -done by passing the ``-v`` argument to ``git format-patch`` with a version -number. - -Lastly please ensure that you also test your revised changes. In particular -please don't just edit the patch file written out by ``git format-patch`` and -resend it. - Submitting Changes to Stable Release Branches ============================================= @@ -610,6 +638,100 @@ follows: and in the following sections but modify the subject header of your patch email to include the name of the stable branch which you are targetting. This can be done using the ``--subject-prefix`` argument to - ``git format-patch``, for example to submit a patch to the dunfell - branch use - ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``. + ``git format-patch``, for example to submit a patch to the + "&DISTRO_NAME_NO_CAP_MINUS_ONE;" branch use:: + + git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ... + +Taking Patch Review into Account +================================ + +You may get feedback on your submitted patches from other community members +or from the automated patchtest service. If issues are identified in your +patches then it is usually necessary to address these before the patches are +accepted into the project. In this case you should your commits according +to the feedback and submit an updated version to the relevant mailing list. + +In any case, never fix reported issues by fixing them in new commits +on the tip of your branch. Always come up with a new series of commits +without the reported issues. + +.. note:: + + It is a good idea to send a copy to the reviewers who provided feedback + to the previous version of the patch. You can make sure this happens + by adding a ``CC`` tag to the commit description:: + + CC: William Shakespeare + +A single patch can be amended using ``git commit --amend``, and multiple +patches can be easily reworked and reordered through an interactive Git rebase:: + + git rebase -i + +See `this tutorial `__ +for practical guidance about using Git interactive rebasing. + +You should also modify the ``[PATCH]`` tag in the email subject line when +sending the revised patch to mark the new iteration as ``[PATCH v2]``, +``[PATCH v3]``, etc as appropriate. This can be done by passing the ``-v`` +argument to ``git format-patch`` with a version number:: + + git format-patch -v2 + +Lastly please ensure that you also test your revised changes. In particular +please don't just edit the patch file written out by ``git format-patch`` and +resend it. + +Tracking the Status of Patches +============================== + +The Yocto Project uses a `Patchwork instance `__ +to track the status of patches submitted to the various mailing lists and to +support automated patch testing. Each submitted patch is checked for common +mistakes and deviations from the expected patch format and submitters are +notified by ``patchtest`` if such mistakes are found. This process helps to +reduce the burden of patch review on maintainers. + +.. note:: + + This system is imperfect and changes can sometimes get lost in the flow. + Asking about the status of a patch or change is reasonable if the change + has been idle for a while with no feedback. + +If your patches have not had any feedback in a few days, they may have already +been merged. You can run ``git pull`` branch to check this. Note that many if +not most layer maintainers do not send out acknowledgement emails when they +accept patches. Alternatively, if there is no response or merge after a few days +the patch may have been missed or the appropriate reviewers may not currently be +around. It is then perfectly fine to reply to it yourself with a reminder asking +for feedback. + +.. note:: + + Patch reviews for feature and recipe upgrade patches are likely be delayed + during a feature freeze because these types of patches aren't merged during + at that time --- you may have to wait until after the freeze is lifted. + +Maintainers also commonly use ``-next`` branches to test submissions prior to +merging patches. Thus, you can get an idea of the status of a patch based on +whether the patch has been merged into one of these branches. The commonly +used testing branches for OpenEmbedded-Core are as follows: + +- *openembedded-core "master-next" branch:* This branch is part of the + :oe_git:`openembedded-core ` repository and contains + proposed changes to the core metadata. + +- *poky "master-next" branch:* This branch is part of the + :yocto_git:`poky ` repository and combines proposed + changes to BitBake, the core metadata and the poky distro. + +Similarly, stable branches maintained by the project may have corresponding +``-next`` branches which collect proposed changes. For example, +``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next`` +branches in both the "openembdedded-core" and "poky" repositories. + +Other layers may have similar testing branches but there is no formal +requirement or standard for these so please check the documentation for the +layers you are contributing to. + From patchwork Fri Aug 18 17:10:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29146 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 315A3FC6165 for ; Fri, 18 Aug 2023 17:10:50 +0000 (UTC) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by mx.groups.io with SMTP id smtpd.web10.2.1692378641859632545 for ; Fri, 18 Aug 2023 10:10:42 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=ArwVNp3v; spf=pass (domain: bootlin.com, ip: 217.70.183.198, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 1D37AC0002; Fri, 18 Aug 2023 17:10:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378639; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GnUhiuwmOVlxb9KWyxFslV02kkrwfVUJWm3B1D2Ip6M=; b=ArwVNp3vtkS7CFhFv0xH3MEt+eGN4hdfqMes6193DA1dbIt//CgLj1zuYCxGYtV2LGQj+Z qs1lnpCD18fAlClURKtKfOXFazfE8ZeuB6HzFO5gFbN5PSHiwGrLdgDvm1O0wqWbKByQA3 73954NkZv70kpxAex7T+yHAfz3fc29sWeNvnygSpw51yMlaCOvlRXEa2RArr2qJlQ6pFXG G0GH3qamLLDjDmysQMk5YfAJQNb+qvq+xalYrmBhllFCcT9goKxqV5XlppI/mesTtTzITl KslgWkblrETQtEVdngVbQIZy4aGUEldkwOH6CdOOTR0a3n1vy4SgsixeSE9NrQ== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 08/10] contributor-guide: submit-changes: improvements to mailing lists section Date: Fri, 18 Aug 2023 19:10:03 +0200 Message-Id: <20230818171005.92381-9-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:50 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4173 From: Michael Opdenacker - Add missing reference to openembedded-devel list - Improve the text to clarify explanations, remove redundant information and include information currently on http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Signed-off-by: Michael Opdenacker --- .../contributor-guide/submit-changes.rst | 29 ++++++++++--------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 3098a76a6c..31674d313d 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -328,14 +328,16 @@ Finding a Suitable Mailing List You should send patches to the appropriate mailing list so that they can be reviewed by the right contributors and merged by the appropriate maintainer. The specific mailing list you need to use depends on the location of the code -you are changing. Each component (e.g. layer) should have a ``README`` file -that indicates where to send the changes and which process to follow. +you are changing. If people have concerns with any of the patches, they will usually voice their concern over the mailing list. If patches do not receive any negative reviews, the maintainer of the affected layer typically takes them, tests them, and then based on successful testing, merges them. +In general, each component (e.g. layer) should have a ``README`` file +that indicates where to send the changes and which process to follow. + The "poky" repository, which is the Yocto Project's reference build environment, is a hybrid repository that contains several individual pieces (e.g. BitBake, Metadata, documentation, and so forth) built using @@ -358,21 +360,22 @@ varies by component: - *Documentation*: For changes to the Yocto Project documentation, use the :yocto_lists:`docs ` mailing list. -For changes to other layers hosted in the Yocto Project source -repositories (i.e. ``yoctoproject.org``) and tools use the +For changes to other layers and tools hosted in the Yocto Project source +repositories (i.e. :yocto_git:`git.yoctoproject.org <>`), use the :yocto_lists:`yocto ` general mailing list. -.. note:: +For changes to other layers hosted in the OpenEmbedded source +repositories (i.e. :oe_git:`git.openembedded.org <>`), use +the :oe_lists:`openembedded-devel ` +mailing list, unless specified otherwise in the layer's ``README`` file. - Sometimes a layer's documentation specifies to use a particular - mailing list. If so, use that list. +If you intend to submit a new recipe that neither fits into the core Metadata, +nor into :oe_git:`meta-openembedded `, you should +look for a suitable layer in https://layers.openembedded.org. If similar +recipes can be expected, you may consider :ref:`dev-manual/layers:creating your own layer`. -For additional recipes that do not fit into the core Metadata, you -should determine which layer the recipe should go into and submit the -changes in the manner recommended by the documentation (e.g. by the -``README`` file) supplied with the layer. If in doubt, please ask on the -:yocto_lists:`yocto ` general mailing list or on the -:oe_lists:`openembedded-devel ` mailing list. +If in doubt, please ask on the :yocto_lists:`yocto ` general mailing list +or on the :oe_lists:`openembedded-devel ` mailing list. Subscribing to the Mailing List ------------------------------- From patchwork Fri Aug 18 17:10:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29144 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 197EBC7EE43 for ; Fri, 18 Aug 2023 17:10:50 +0000 (UTC) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx.groups.io with SMTP id smtpd.web10.3.1692378644880591361 for ; Fri, 18 Aug 2023 10:10:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=ATch/CZz; spf=pass (domain: bootlin.com, ip: 217.70.183.197, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id A7C161C0002; Fri, 18 Aug 2023 17:10:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378643; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2XFVNNH+J8OmF8kpGwzidYZQ2sObJqhwrIIeoc92MgI=; b=ATch/CZzzSxloCYTQ0OY1hwqIXLfXN8KMurIYhNvVInumasEUnYdL0fKgcsjOFDbqUFAKN DJ6Y2o9v2Z9z/BV0fw8/WmEJdHe59nBa23+19H4g7+qH906pIK8PcSCFGrWIAXm7Ou62GL LSIJlPg4jEaOBRG6rV1Bgxu704OAithQebo/K4oTPJJ5z0C4XNUkjVsiMNp6c27ubUt/iM yw6O4p3QEEippDerq8xKDY4I6Qg7XJ+YtA5nOSFWeRqO47BywFyZjtN86JLIJEaEYlEV1z aV3efIvV048S6Y+u3aoLcPZF2r60G/PhU/DJkKTJQBylt0ccBNV9xrwScqBRLQ== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 09/10] contributor-guide: submit-changes: commit guidelines for recipes Date: Fri, 18 Aug 2023 19:10:04 +0200 Message-Id: <20230818171005.92381-10-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:50 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4174 From: Michael Opdenacker Adding text currently on http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Signed-off-by: Michael Opdenacker --- documentation/contributor-guide/submit-changes.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 31674d313d..677885e3cf 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -101,6 +101,11 @@ corresponding to each of the patches you will eventually submit. See `further guidance `__ in the Linux kernel documentation if needed. +For example, when you intend to add multiple new recipes, each recipe +should be added in a separate commit. For upgrades to existing recipes, +the previous version should usually be deleted as part of the same commit +to add the upgraded version. + #. *Stage Your Changes:* Stage your changes by using the ``git add`` command on each file you modified. If you want to stage all the files you modified, you can even use the ``git add -A`` command. From patchwork Fri Aug 18 17:10:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 29145 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DC29C83003 for ; Fri, 18 Aug 2023 17:10:50 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx.groups.io with SMTP id smtpd.web11.3.1692378645951233014 for ; Fri, 18 Aug 2023 10:10:46 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=ahDRCrwW; spf=pass (domain: bootlin.com, ip: 217.70.183.195, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 6800F60002; Fri, 18 Aug 2023 17:10:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1692378644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Poysrfyzy96ViwkXZkPjr9Bj93srDygfx+XszK2JboU=; b=ahDRCrwWLMdoOjAVURUrPici8kFKNXEF22K9CaBSaDHsXtggRS8rIZuRDY/3G/HYZomqJD KUnSSvCZUnGKj4twoPre88tXi0B0pQEh8zmK1uhBQtnXr9FCIUwvRg0j24LdTCIwTVO3Nb heTGeAmmwnwb9uJ0/TVL1kF7qMabhGJ+4J5LTOD4lYsEjbwIoSnPiBTw3Luzy6SF9GWvxk ZASnzJG2WWeJrfMphSV1DZkvx2wS9p2ewLwtpwLpn99PcBjpq8vAEzabUEawp2hSlsYSzZ I5ItjtMf/YixK/Mtbg15WlO+haC6zV88X3PqEzAeZBU5+VLHGo8OZutB4x6VhA== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Jon.Mason@arm.com, JPEWhacker@gmail.com, Michael Opdenacker Subject: [PATCH 10/10] contributor-guide: submit-changes: how to request push access to repositories Date: Fri, 18 Aug 2023 19:10:05 +0200 Message-Id: <20230818171005.92381-11-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230818171005.92381-1-michael.opdenacker@bootlin.com> References: <20230818171005.92381-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Fri, 18 Aug 2023 17:10:50 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4175 From: Michael Opdenacker Including content currently on http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Signed-off-by: Michael Opdenacker --- .../contributor-guide/submit-changes.rst | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 677885e3cf..cda2d12d25 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -502,9 +502,18 @@ have been followed: in the `Git Community Book `__. -#. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for - permissions to push to an upstream contrib repository, push the - change to that repository:: +#. *Request Push Access to an "Upstream" Contrib Repository:* Send an email to + ``helpdesk@yoctoproject.org``: + + - Attach your SSH public key which usually named ``id_rsa.pub.``. + If you don't have one generate it by running ``ssh-keygen -t rsa -b 4096 -C "your_email@example.com"``. + + - List the repositories you're planning to contribute to. + + - Include your preferred branch prefix for ``-contrib`` repositories. + +#. *Push Your Commits to the "Contrib" Upstream:* Push your + changes to that repository:: $ git push upstream_remote_repo local_branch_name