1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK 2 3Contributing Changes to a Component 4************************************ 5 6Contributions to the Yocto Project and OpenEmbedded are very welcome. 7Because the system is extremely configurable and flexible, we recognize 8that developers will want to extend, configure or optimize it for their 9specific uses. 10 11.. _ref-why-mailing-lists: 12 13Contributing through mailing lists --- Why not using web-based workflows? 14========================================================================= 15 16Both Yocto Project and OpenEmbedded have many key components that are 17maintained by patches being submitted on mailing lists. We appreciate this 18approach does look a little old fashioned when other workflows are available 19through web technology such as GitHub, GitLab and others. Since we are often 20asked this question, we’ve decided to document the reasons for using mailing 21lists. 22 23One significant factor is that we value peer review. When a change is proposed 24to many of the core pieces of the project, it helps to have many eyes of review 25go over them. Whilst there is ultimately one maintainer who needs to make the 26final call on accepting or rejecting a patch, the review is made by many eyes 27and the exact people reviewing it are likely unknown to the maintainer. It is 28often the surprise reviewer that catches the most interesting issues! 29 30This is in contrast to the "GitHub" style workflow where either just a 31maintainer makes that review, or review is specifically requested from 32nominated people. We believe there is significant value added to the codebase 33by this peer review and that moving away from mailing lists would be to the 34detriment of our code. 35 36We also need to acknowledge that many of our developers are used to this 37mailing list workflow and have worked with it for years, with tools and 38processes built around it. Changing away from this would result in a loss 39of key people from the project, which would again be to its detriment. 40 41The projects are acutely aware that potential new contributors find the 42mailing list approach off-putting and would prefer a web-based GUI. 43Since we don’t believe that can work for us, the project is aiming to ensure 44`patchwork <https://patchwork.yoctoproject.org/>`__ is available to help track 45patch status and also looking at how tooling can provide more feedback to users 46about patch status. We are looking at improving tools such as ``patchtest`` to 47test user contributions before they hit the mailing lists and also at better 48documenting how to use such workflows since we recognise that whilst this was 49common knowledge a decade ago, it might not be as familiar now. 50 51Preparing Changes for Submission 52================================ 53 54Set up Git 55---------- 56 57The first thing to do is to install Git packages. Here is an example 58on Debian and Ubuntu:: 59 60 sudo aptitude install git-core git-email 61 62Then, you need to set a name and e-mail address that Git will 63use to identify your commits:: 64 65 git config --global user.name "Ada Lovelace" 66 git config --global user.email "ada.lovelace@gmail.com" 67 68Clone the Git repository for the component to modify 69---------------------------------------------------- 70 71After identifying the component to modify as described in the 72":doc:`../contributor-guide/identify-component`" section, clone the 73corresponding Git repository. Here is an example for OpenEmbedded-Core:: 74 75 git clone https://git.openembedded.org/openembedded-core 76 cd openembedded-core 77 78Create a new branch 79------------------- 80 81Then, create a new branch in your local Git repository 82for your changes, starting from the reference branch in the upstream 83repository (often called ``master``):: 84 85 $ git checkout <ref-branch> 86 $ git checkout -b my-changes 87 88If you have completely unrelated sets of changes to submit, you should even 89create one branch for each set. 90 91Implement and commit changes 92---------------------------- 93 94In each branch, you should group your changes into small, controlled and 95isolated ones. Keeping changes small and isolated aids review, makes 96merging/rebasing easier and keeps the change history clean should anyone need 97to refer to it in future. 98 99To this purpose, you should create *one Git commit per change*, 100corresponding to each of the patches you will eventually submit. 101See `further guidance <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes>`__ 102in the Linux kernel documentation if needed. 103 104For example, when you intend to add multiple new recipes, each recipe 105should be added in a separate commit. For upgrades to existing recipes, 106the previous version should usually be deleted as part of the same commit 107to add the upgraded version. 108 109#. *Stage Your Changes:* Stage your changes by using the ``git add`` 110 command on each file you modified. If you want to stage all the 111 files you modified, you can even use the ``git add -A`` command. 112 113#. *Commit Your Changes:* This is when you can create separate commits. For 114 each commit to create, use the ``git commit -s`` command with the files 115 or directories you want to include in the commit:: 116 117 $ git commit -s file1 file2 dir1 dir2 ... 118 119 To include **a**\ ll staged files:: 120 121 $ git commit -sa 122 123 - The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line 124 to your commit message. There is the same requirement for contributing 125 to the Linux kernel. Adding such a line signifies that you, the 126 submitter, have agreed to the `Developer's Certificate of Origin 1.1 127 <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__ 128 as follows: 129 130 .. code-block:: none 131 132 Developer's Certificate of Origin 1.1 133 134 By making a contribution to this project, I certify that: 135 136 (a) The contribution was created in whole or in part by me and I 137 have the right to submit it under the open source license 138 indicated in the file; or 139 140 (b) The contribution is based upon previous work that, to the best 141 of my knowledge, is covered under an appropriate open source 142 license and I have the right under that license to submit that 143 work with modifications, whether created in whole or in part 144 by me, under the same open source license (unless I am 145 permitted to submit under a different license), as indicated 146 in the file; or 147 148 (c) The contribution was provided directly to me by some other 149 person who certified (a), (b) or (c) and I have not modified 150 it. 151 152 (d) I understand and agree that this project and the contribution 153 are public and that a record of the contribution (including all 154 personal information I submit with it, including my sign-off) is 155 maintained indefinitely and may be redistributed consistent with 156 this project or the open source license(s) involved. 157 158 - Provide a single-line summary of the change and, if more 159 explanation is needed, provide more detail in the body of the 160 commit. This summary is typically viewable in the "shortlist" of 161 changes. Thus, providing something short and descriptive that 162 gives the reader a summary of the change is useful when viewing a 163 list of many commits. You should prefix this short description 164 with the recipe name (if changing a recipe), or else with the 165 short form path to the file being changed. 166 167 .. note:: 168 169 To find a suitable prefix for the commit summary, a good idea 170 is to look for prefixes used in previous commits touching the 171 same files or directories:: 172 173 git log --oneline <paths> 174 175 - For the body of the commit message, provide detailed information 176 that describes what you changed, why you made the change, and the 177 approach you used. It might also be helpful if you mention how you 178 tested the change. Provide as much detail as you can in the body 179 of the commit message. 180 181 .. note:: 182 183 If the single line summary is enough to describe a simple 184 change, the body of the commit message can be left empty. 185 186 - If the change addresses a specific bug or issue that is associated 187 with a bug-tracking ID, include a reference to that ID in your 188 detailed description. For example, the Yocto Project uses a 189 specific convention for bug references --- any commit that addresses 190 a specific bug should use the following form for the detailed 191 description. Be sure to use the actual bug-tracking ID from 192 Bugzilla for bug-id:: 193 194 Fixes [YOCTO #bug-id] 195 196 detailed description of change 197 198#. *Crediting contributors:* By using the ``git commit --amend`` command, 199 you can add some tags to the commit description to credit other contributors 200 to the change: 201 202 - ``Reported-by``: name and email of a person reporting a bug 203 that your commit is trying to fix. This is a good practice 204 to encourage people to go on reporting bugs and let them 205 know that their reports are taken into account. 206 207 - ``Suggested-by``: name and email of a person to credit for the 208 idea of making the change. 209 210 - ``Tested-by``, ``Reviewed-by``: name and email for people having 211 tested your changes or reviewed their code. These fields are 212 usually added by the maintainer accepting a patch, or by 213 yourself if you submitted your patches to early reviewers, 214 or are submitting an unmodified patch again as part of a 215 new iteration of your patch series. 216 217 - ``CC:`` Name and email of people you want to send a copy 218 of your changes to. This field will be used by ``git send-email``. 219 220 See `more guidance about using such tags 221 <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`__ 222 in the Linux kernel documentation. 223 224Creating Patches 225================ 226 227Here is the general procedure on how to create patches to be sent through email: 228 229#. *Describe the Changes in your Branch:* If you have more than one commit 230 in your branch, it's recommended to provide a cover letter describing 231 the series of patches you are about to send. 232 233 For this purpose, a good solution is to store the cover letter contents 234 in the branch itself:: 235 236 git branch --edit-description 237 238 This will open a text editor to fill in the description for your 239 changes. This description can be updated when necessary and will 240 be used by Git to create the cover letter together with the patches. 241 242 It is recommended to start this description with a title line which 243 will serve a the subject line for the cover letter. 244 245#. *Generate Patches for your Branch:* The ``git format-patch`` command will 246 generate patch files for each of the commits in your branch. You need 247 to pass the reference branch your branch starts from. 248 249 If you branch didn't need a description in the previous step:: 250 251 $ git format-patch <ref-branch> 252 253 If you filled a description for your branch, you will want to generate 254 a cover letter too:: 255 256 $ git format-patch --cover-letter --cover-from-description=auto <ref-branch> 257 258 After the command is run, the current directory contains numbered 259 ``.patch`` files for the commits in your branch. If you have a cover 260 letter, it will be in the ``0000-cover-letter.patch``. 261 262 .. note:: 263 264 The ``--cover-from-description=auto`` option makes ``git format-patch`` 265 use the first paragraph of the branch description as the cover 266 letter title. Another possibility, which is easier to remember, is to pass 267 only the ``--cover-letter`` option, but you will have to edit the 268 subject line manually every time you generate the patches. 269 270 See the `git format-patch manual page <https://git-scm.com/docs/git-format-patch>`__ 271 for details. 272 273#. *Review each of the Patch Files:* This final review of the patches 274 before sending them often allows to view your changes from a different 275 perspective and discover defects such as typos, spacing issues or lines 276 or even files that you didn't intend to modify. This review should 277 include the cover letter patch too. 278 279 If necessary, rework your commits as described in 280 ":ref:`contributor-guide/submit-changes:taking patch review into account`". 281 282Sending the Patches via Email 283============================= 284 285Using Git to Send Patches 286------------------------- 287 288To submit patches through email, it is very important that you send them 289without any whitespace or HTML formatting that either you or your mailer 290introduces. The maintainer that receives your patches needs to be able 291to save and apply them directly from your emails, using the ``git am`` 292command. 293 294Using the ``git send-email`` command is the only error-proof way of sending 295your patches using email since there is no risk of compromising whitespace 296in the body of the message, which can occur when you use your own mail 297client. It will also properly include your patches as *inline attachments*, 298which is not easy to do with standard e-mail clients without breaking lines. 299If you used your regular e-mail client and shared your patches as regular 300attachments, reviewers wouldn't be able to quote specific sections of your 301changes and make comments about them. 302 303Setting up Git to Send Email 304---------------------------- 305 306The ``git send-email`` command can send email by using a local or remote 307Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or 308through a direct SMTP configuration in your Git ``~/.gitconfig`` file. 309 310Here are the settings for letting ``git send-email`` send e-mail through your 311regular STMP server, using a Google Mail account as an example:: 312 313 git config --global sendemail.smtpserver smtp.gmail.com 314 git config --global sendemail.smtpserverport 587 315 git config --global sendemail.smtpencryption tls 316 git config --global sendemail.smtpuser ada.lovelace@gmail.com 317 git config --global sendemail.smtppass = XXXXXXXX 318 319These settings will appear in the ``.gitconfig`` file in your home directory. 320 321If you neither can use a local MTA nor SMTP, make sure you use an email client 322that does not touch the message (turning spaces in tabs, wrapping lines, etc.). 323A good mail client to do so is Pine (or Alpine) or Mutt. For more 324information about suitable clients, see `Email clients info for Linux 325<https://www.kernel.org/doc/html/latest/process/email-clients.html>`__ 326in the Linux kernel sources. 327 328If you use such clients, just include the patch in the body of your email. 329 330Finding a Suitable Mailing List 331------------------------------- 332 333You should send patches to the appropriate mailing list so that they can be 334reviewed by the right contributors and merged by the appropriate maintainer. 335The specific mailing list you need to use depends on the location of the code 336you are changing. 337 338If people have concerns with any of the patches, they will usually voice 339their concern over the mailing list. If patches do not receive any negative 340reviews, the maintainer of the affected layer typically takes them, tests them, 341and then based on successful testing, merges them. 342 343In general, each component (e.g. layer) should have a ``README`` file 344that indicates where to send the changes and which process to follow. 345 346The "poky" repository, which is the Yocto Project's reference build 347environment, is a hybrid repository that contains several individual 348pieces (e.g. BitBake, Metadata, documentation, and so forth) built using 349the combo-layer tool. The upstream location used for submitting changes 350varies by component: 351 352- *Core Metadata:* Send your patches to the 353 :oe_lists:`openembedded-core </g/openembedded-core>` 354 mailing list. For example, a change to anything under the ``meta`` or 355 ``scripts`` directories should be sent to this mailing list. 356 357- *BitBake:* For changes to BitBake (i.e. anything under the 358 ``bitbake`` directory), send your patches to the 359 :oe_lists:`bitbake-devel </g/bitbake-devel>` 360 mailing list. 361 362- *"meta-\*" trees:* These trees contain Metadata. Use the 363 :yocto_lists:`poky </g/poky>` mailing list. 364 365- *Documentation*: For changes to the Yocto Project documentation, use the 366 :yocto_lists:`docs </g/docs>` mailing list. 367 368For changes to other layers and tools hosted in the Yocto Project source 369repositories (i.e. :yocto_git:`git.yoctoproject.org <>`), use the 370:yocto_lists:`yocto </g/yocto/>` general mailing list. 371 372For changes to other layers hosted in the OpenEmbedded source 373repositories (i.e. :oe_git:`git.openembedded.org <>`), use 374the :oe_lists:`openembedded-devel </g/openembedded-devel>` 375mailing list, unless specified otherwise in the layer's ``README`` file. 376 377If you intend to submit a new recipe that neither fits into the core Metadata, 378nor into :oe_git:`meta-openembedded </meta-openembedded/>`, you should 379look for a suitable layer in https://layers.openembedded.org. If similar 380recipes can be expected, you may consider :ref:`dev-manual/layers:creating your own layer`. 381 382If in doubt, please ask on the :yocto_lists:`yocto </g/yocto/>` general mailing list 383or on the :oe_lists:`openembedded-devel </g/openembedded-devel>` mailing list. 384 385Subscribing to the Mailing List 386------------------------------- 387 388After identifying the right mailing list to use, you will have to subscribe to 389it if you haven't done it yet. 390 391If you attempt to send patches to a list you haven't subscribed to, your email 392will be returned as undelivered. 393 394However, if you don't want to be receive all the messages sent to a mailing list, 395you can set your subscription to "no email". You will still be a subscriber able 396to send messages, but you won't receive any e-mail. If people reply to your message, 397their e-mail clients will default to including your email address in the 398conversation anyway. 399 400Anyway, you'll also be able to access the new messages on mailing list archives, 401either through a web browser, or for the lists archived on https://lore.kernelorg, 402through an individual newsgroup feed or a git repository. 403 404Sending Patches via Email 405------------------------- 406 407At this stage, you are ready to send your patches via email. Here's the 408typical usage of ``git send-email``:: 409 410 git send-email --to <mailing-list-address> *.patch 411 412Then, review each subject line and list of recipients carefully, and then 413and then allow the command to send each message. 414 415You will see that ``git send-email`` will automatically copy the people listed 416in any commit tags such as ``Signed-off-by`` or ``Reported-by``. 417 418In case you are sending patches for :oe_git:`meta-openembedded </meta-openembedded/>` 419or any layer other than :oe_git:`openembedded-core </openembedded-core/>`, 420please add the appropriate prefix so that it is clear which layer the patch is intended 421to be applied to:: 422 423 git send-email --subject-prefix="meta-oe][PATCH" ... 424 425.. note:: 426 427 It is actually possible to send patches without generating them 428 first. However, make sure you have reviewed your changes carefully 429 because ``git send-email`` will just show you the title lines of 430 each patch. 431 432 Here's a command you can use if you just have one patch in your 433 branch:: 434 435 git send-email --to <mailing-list-address> -1 436 437 If you have multiple patches and a cover letter, you can send 438 patches for all the commits between the reference branch 439 and the tip of your branch:: 440 441 git send-email --cover-letter --cover-from-description=auto --to <mailing-list-address> -M <ref-branch> 442 443See the `git send-email manual page <https://git-scm.com/docs/git-send-email>`__ 444for details. 445 446Troubleshooting Email Issues 447---------------------------- 448 449Fixing your From identity 450~~~~~~~~~~~~~~~~~~~~~~~~~ 451 452We have a frequent issue with contributors whose patches are received through 453a ``From`` field which doesn't match the ``Signed-off-by`` information. Here is 454a typical example for people sending from a domain name with :wikipedia:`DMARC`:: 455 456 From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>" 457 458This ``From`` field is used by ``git am`` to recreate commits with the right 459author name. The following will ensure that your e-mails have an additional 460``From`` field at the beginning of the Email body, and therefore that 461maintainers accepting your patches don't have to fix commit author information 462manually:: 463 464 git config --global sendemail.from "linus.torvalds@kernel.org" 465 466The ``sendemail.from`` should match your ``user.email`` setting, 467which appears in the ``Signed-off-by`` line of your commits. 468 469Streamlining git send-email usage 470--------------------------------- 471 472If you want to save time and not be forced to remember the right options to use 473with ``git send-email``, you can use Git configuration settings. 474 475- To set the right mailing list address for a given repository:: 476 477 git config --local sendemail.to openembedded-devel@lists.openembedded.org 478 479- If the mailing list requires a subject prefix for the layer 480 (this only works when the repository only contains one layer):: 481 482 git config --local format.subjectprefix "meta-something][PATCH" 483 484Using Scripts to Push a Change Upstream and Request a Pull 485========================================================== 486 487For larger patch series it is preferable to send a pull request which not 488only includes the patch but also a pointer to a branch that can be pulled 489from. This involves making a local branch for your changes, pushing this 490branch to an accessible repository and then using the ``create-pull-request`` 491and ``send-pull-request`` scripts from openembedded-core to create and send a 492patch series with a link to the branch for review. 493 494Follow this procedure to push a change to an upstream "contrib" Git 495repository once the steps in 496":ref:`contributor-guide/submit-changes:preparing changes for submission`" 497have been followed: 498 499.. note:: 500 501 You can find general Git information on how to push a change upstream 502 in the 503 `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__. 504 505#. *Request Push Access to an "Upstream" Contrib Repository:* Send an email to 506 ``helpdesk@yoctoproject.org``: 507 508 - Attach your SSH public key which usually named ``id_rsa.pub.``. 509 If you don't have one generate it by running ``ssh-keygen -t rsa -b 4096 -C "your_email@example.com"``. 510 511 - List the repositories you're planning to contribute to. 512 513 - Include your preferred branch prefix for ``-contrib`` repositories. 514 515#. *Push Your Commits to the "Contrib" Upstream:* Push your 516 changes to that repository:: 517 518 $ git push upstream_remote_repo local_branch_name 519 520 For example, suppose you have permissions to push 521 into the upstream ``meta-intel-contrib`` repository and you are 522 working in a local branch named `your_name`\ ``/README``. The following 523 command pushes your local commits to the ``meta-intel-contrib`` 524 upstream repository and puts the commit in a branch named 525 `your_name`\ ``/README``:: 526 527 $ git push meta-intel-contrib your_name/README 528 529#. *Determine Who to Notify:* Determine the maintainer or the mailing 530 list that you need to notify for the change. 531 532 Before submitting any change, you need to be sure who the maintainer 533 is or what mailing list that you need to notify. Use either these 534 methods to find out: 535 536 - *Maintenance File:* Examine the ``maintainers.inc`` file, which is 537 located in the :term:`Source Directory` at 538 ``meta/conf/distro/include``, to see who is responsible for code. 539 540 - *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can 541 enter the following command to bring up a short list of all 542 commits against a specific file:: 543 544 git shortlog -- filename 545 546 Just provide the name of the file for which you are interested. The 547 information returned is not ordered by history but does include a 548 list of everyone who has committed grouped by name. From the list, 549 you can see who is responsible for the bulk of the changes against 550 the file. 551 552 - *Find the Mailing List to Use:* See the 553 ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" 554 section above. 555 556#. *Make a Pull Request:* Notify the maintainer or the mailing list that 557 you have pushed a change by making a pull request. 558 559 The Yocto Project provides two scripts that conveniently let you 560 generate and send pull requests to the Yocto Project. These scripts 561 are ``create-pull-request`` and ``send-pull-request``. You can find 562 these scripts in the ``scripts`` directory within the 563 :term:`Source Directory` (e.g. 564 ``poky/scripts``). 565 566 Using these scripts correctly formats the requests without 567 introducing any whitespace or HTML formatting. The maintainer that 568 receives your patches either directly or through the mailing list 569 needs to be able to save and apply them directly from your emails. 570 Using these scripts is the preferred method for sending patches. 571 572 First, create the pull request. For example, the following command 573 runs the script, specifies the upstream repository in the contrib 574 directory into which you pushed the change, and provides a subject 575 line in the created patch files:: 576 577 $ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README" 578 579 Running this script forms ``*.patch`` files in a folder named 580 ``pull-``\ `PID` in the current directory. One of the patch files is a 581 cover letter. 582 583 Before running the ``send-pull-request`` script, you must edit the 584 cover letter patch to insert information about your change. After 585 editing the cover letter, send the pull request. For example, the 586 following command runs the script and specifies the patch directory 587 and email address. In this example, the email address is a mailing 588 list:: 589 590 $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org 591 592 You need to follow the prompts as the script is interactive. 593 594 .. note:: 595 596 For help on using these scripts, simply provide the ``-h`` 597 argument as follows:: 598 599 $ poky/scripts/create-pull-request -h 600 $ poky/scripts/send-pull-request -h 601 602Submitting Changes to Stable Release Branches 603============================================= 604 605The process for proposing changes to a Yocto Project stable branch differs 606from the steps described above. Changes to a stable branch must address 607identified bugs or CVEs and should be made carefully in order to avoid the 608risk of introducing new bugs or breaking backwards compatibility. Typically 609bug fixes must already be accepted into the master branch before they can be 610backported to a stable branch unless the bug in question does not affect the 611master branch or the fix on the master branch is unsuitable for backporting. 612 613The list of stable branches along with the status and maintainer for each 614branch can be obtained from the 615:yocto_wiki:`Releases wiki page </Releases>`. 616 617.. note:: 618 619 Changes will not typically be accepted for branches which are marked as 620 End-Of-Life (EOL). 621 622With this in mind, the steps to submit a change for a stable branch are as 623follows: 624 625#. *Identify the bug or CVE to be fixed:* This information should be 626 collected so that it can be included in your submission. 627 628 See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities` 629 for details about CVE tracking. 630 631#. *Check if the fix is already present in the master branch:* This will 632 result in the most straightforward path into the stable branch for the 633 fix. 634 635 #. *If the fix is present in the master branch --- submit a backport request 636 by email:* You should send an email to the relevant stable branch 637 maintainer and the mailing list with details of the bug or CVE to be 638 fixed, the commit hash on the master branch that fixes the issue and 639 the stable branches which you would like this fix to be backported to. 640 641 #. *If the fix is not present in the master branch --- submit the fix to the 642 master branch first:* This will ensure that the fix passes through the 643 project's usual patch review and test processes before being accepted. 644 It will also ensure that bugs are not left unresolved in the master 645 branch itself. Once the fix is accepted in the master branch a backport 646 request can be submitted as above. 647 648 #. *If the fix is unsuitable for the master branch --- submit a patch 649 directly for the stable branch:* This method should be considered as a 650 last resort. It is typically necessary when the master branch is using 651 a newer version of the software which includes an upstream fix for the 652 issue or when the issue has been fixed on the master branch in a way 653 that introduces backwards incompatible changes. In this case follow the 654 steps in ":ref:`contributor-guide/submit-changes:preparing changes for submission`" 655 and in the following sections but modify the subject header of your patch 656 email to include the name of the stable branch which you are 657 targetting. This can be done using the ``--subject-prefix`` argument to 658 ``git format-patch``, for example to submit a patch to the 659 "&DISTRO_NAME_NO_CAP_MINUS_ONE;" branch use:: 660 661 git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ... 662 663Taking Patch Review into Account 664================================ 665 666You may get feedback on your submitted patches from other community members 667or from the automated patchtest service. If issues are identified in your 668patches then it is usually necessary to address these before the patches are 669accepted into the project. In this case you should your commits according 670to the feedback and submit an updated version to the relevant mailing list. 671 672In any case, never fix reported issues by fixing them in new commits 673on the tip of your branch. Always come up with a new series of commits 674without the reported issues. 675 676.. note:: 677 678 It is a good idea to send a copy to the reviewers who provided feedback 679 to the previous version of the patch. You can make sure this happens 680 by adding a ``CC`` tag to the commit description:: 681 682 CC: William Shakespeare <bill@yoctoproject.org> 683 684A single patch can be amended using ``git commit --amend``, and multiple 685patches can be easily reworked and reordered through an interactive Git rebase:: 686 687 git rebase -i <ref-branch> 688 689See `this tutorial <https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d>`__ 690for practical guidance about using Git interactive rebasing. 691 692You should also modify the ``[PATCH]`` tag in the email subject line when 693sending the revised patch to mark the new iteration as ``[PATCH v2]``, 694``[PATCH v3]``, etc as appropriate. This can be done by passing the ``-v`` 695argument to ``git format-patch`` with a version number:: 696 697 git format-patch -v2 <ref-branch> 698 699Lastly please ensure that you also test your revised changes. In particular 700please don't just edit the patch file written out by ``git format-patch`` and 701resend it. 702 703Tracking the Status of Patches 704============================== 705 706The Yocto Project uses a `Patchwork instance <https://patchwork.yoctoproject.org/>`__ 707to track the status of patches submitted to the various mailing lists and to 708support automated patch testing. Each submitted patch is checked for common 709mistakes and deviations from the expected patch format and submitters are 710notified by ``patchtest`` if such mistakes are found. This process helps to 711reduce the burden of patch review on maintainers. 712 713.. note:: 714 715 This system is imperfect and changes can sometimes get lost in the flow. 716 Asking about the status of a patch or change is reasonable if the change 717 has been idle for a while with no feedback. 718 719If your patches have not had any feedback in a few days, they may have already 720been merged. You can run ``git pull`` branch to check this. Note that many if 721not most layer maintainers do not send out acknowledgement emails when they 722accept patches. Alternatively, if there is no response or merge after a few days 723the patch may have been missed or the appropriate reviewers may not currently be 724around. It is then perfectly fine to reply to it yourself with a reminder asking 725for feedback. 726 727.. note:: 728 729 Patch reviews for feature and recipe upgrade patches are likely be delayed 730 during a feature freeze because these types of patches aren't merged during 731 at that time --- you may have to wait until after the freeze is lifted. 732 733Maintainers also commonly use ``-next`` branches to test submissions prior to 734merging patches. Thus, you can get an idea of the status of a patch based on 735whether the patch has been merged into one of these branches. The commonly 736used testing branches for OpenEmbedded-Core are as follows: 737 738- *openembedded-core "master-next" branch:* This branch is part of the 739 :oe_git:`openembedded-core </openembedded-core/>` repository and contains 740 proposed changes to the core metadata. 741 742- *poky "master-next" branch:* This branch is part of the 743 :yocto_git:`poky </poky/>` repository and combines proposed 744 changes to BitBake, the core metadata and the poky distro. 745 746Similarly, stable branches maintained by the project may have corresponding 747``-next`` branches which collect proposed changes. For example, 748``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next`` 749branches in both the "openembdedded-core" and "poky" repositories. 750 751Other layers may have similar testing branches but there is no formal 752requirement or standard for these so please check the documentation for the 753layers you are contributing to. 754 755